=275.Please refer to RP-234035 for detailed scope of the WI.
[116-R19-Duplex] – Xinghua (Huawei)
Email discussion on Rel-19 SBFD
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2400111 Workplan for Evolution of NR Duplex Operation Huawei, HiSilicon
Including semi-static indication of SBFD resources.
R1-2400557 Discussion on reception and transmission procedure for SBFD operation xiaomi
Decision: The document is noted.
R1-2400838 On SBFD TX/RX/measurement procedures Nokia, Nokia Shanghai Bell
Decision: The document is noted.
R1-2400053 Discussion on SBFD TX/RX/measurement procedures Spreadtrum Communications
R1-2400108 On subband full duplex design Huawei, HiSilicon
R1-2400154 Discussion for SBFD TX/RX/measurement procedures New H3C Technologies Co., Ltd.
R1-2400177 Discussion on SBFD TX/RX/measurement procedures Tejas Network Limited
R1-2400207 Discussion on SBFD operation Transsion Holdings
R1-2400241 Discussion on Rel-19 SBFD operation vivo
R1-2400269 Discussion on SBFD TX/RX/measurement procedures TCL
R1-2400300 Discussion on transmission, reception and measurement procedures for SBFD operation ZTE
R1-2400325 Discussion on SBFD TX/RX/measurement procedures CMCC
R1-2400432 Discussion on SBFD TX/RX/measurement procedures CATT
R1-2400606 Discussion on SBFD Tx/Rx/measurement procedures OPPO
R1-2400643 SBFD procedures in RRC_CONNECTED mode Sharp
R1-2400660 Discussion on SBFD TX/RX/measurement procedures China Telecom
R1-2400687 Discussion on SBFD TX RX and measurement procedures InterDigital, Inc.
R1-2400731 SBFD operation and procedures Samsung
R1-2400775 Discussion on Tx/Rx/Measurement procedures for SBFD operation Fujitsu
R1-2400802 Discussion on subband non-overlapping full duplex Tx-Rx and measurement operations NEC
R1-2400826 Discussion on SBFD TX/RX/measurement procedures Panasonic
R1-2400852 SBFD operations Sony
R1-2401011 Views on SBFD TX/RX/measurement procedures Apple
R1-2401081 On semi-static indication of SBFD resources Google Inc.
R1-2401116 Discussion on SBFD TX/RX/measurement procedures NTT DOCOMO, INC.
R1-2401159 Considerations on SBFD Tx/Rx/measurement procedure KT Corp.
R1-2401188 Discussion on SBFD TX/RX/measurement procedures ITRI
R1-2401191 Tx Rx procedure for SBFD ASUSTeK
R1-2401214 Discussion on SBFD TX/RX/measurement procedures WILUS
R1-2401217 SBFD TX/RX/measurement procedures Ericsson
R1-2401227 Discussion on SBFD TX/RX/measurement procedures ETRI
R1-2401249 Discussion on SBFD TX/RX/measurement procedures LG Electronics
R1-2401263 Views on sub-band full duplex operations Lenovo
R1-2401273 Discussion on SBFD TX/RX/ measurement procedures CEWiT
R1-2401294 Discussion on SBFD TX/RX/measurement procedures MediaTek Inc.
R1-2401440 SBFD Transmission, Reception and Measurement Procedures Qualcomm Incorporated
R1-2401652 Summary #1 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Tuesday session
Agreement
For RRC connected mode UEs, at least cell-specific configuration on time and frequency(working assumption) location of SBFD subbands is supported within a TDD carrier.
· FFS: Additional support of UE-specific configuration on time and/or frequency locations of SBFD subbands
Agreement:
For RRC connected mode UEs, SBFD subband time locations are configured within a period. At least when only one TDD-UL-DL pattern is configured, the period is down-selected from one of the following options.
· Option 1: The period is the same as TDD-UL-DL pattern period configured by dl-UL-TransmissionPeriodicity in TDD-UL-DL-ConfigCommon.
· Option 2: The period is integer multiple of TDD-UL-DL pattern period configured by dl-UL-TransmissionPeriodicity in TDD-UL-DL-ConfigCommon.
· FFS: Further details
FFS: Details when two TDD-UL-DL patterns are configured.
Agreement: (confirmed as shown in Thursday session)r
A slot can consist of SBFD symbols and non-SBFD symbols.
Symbol-level
granularity is supported for semi-static indication of SBFD subband time
location.
Agreement:
The maximum number of UL subbands for SBFD operation in an SBFD symbol within a TDD carrier is one.
The UL subband can be located at one side of the carrier or can be located at the middle part of the carrier.
For semi-static indication of SBFD subband frequency location, down-select from the following options.
· Option 1: Frequency locations of UL subband and DL subband(s) are explicitly configured. Guardband(s) if any are implicitly derived as the RBs which are not within UL subband or DL subband(s).
· Option 2: Frequency location of UL subband and the number of RBs for guardband(s), if any, are explicitly configured. DL subband(s) are implicitly derived as RBs which are not within UL subband or guardband(s).
R1-2401653 Summary #2 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Thursday session
Agreement
A slot can consist of SBFD symbols and non-SBFD symbols.
For semi-static indication of SBFD subband time location,
Agreement
The subband frequency-domain resources are same across different SBFD symbols within a TDD carrier. Frequency location of cell specific UL subband, and DL subband(s) if explicitly indicated, are indicated with reference to CRB grid.
R1-2401654 Summary #3 of SBFD TX/RX/measurement procedures Moderator (CATT)
Agreement
For discussion purpose, UL subband frequency resources within active UL BWP are called UL usable PRBs and DL subband(s) frequency resources within active DL BWP are called DL usable PRBs.
For determining UL/DL usable PRBs, consider the following options.
· Option 1: UL usable PRBs are determined as intersection between cell-specific UL subband and active UL BWP in SBFD symbols. DL usable PRBs are determined as intersection between cell-specific DL subband(s) and active DL BWP in SBFD symbols.
· Option 2: UL/DL usable PRBs are explicitly configured within active UL/DL BWP in SBFD symbols.
Agreement
For SBFD-aware UE transmission and reception in the SBFD symbols configured in DL and/or flexible in TDD-UL-DL-ConfigCommon,
CLI measurement behaviours for SBFD-aware UE are discussed in agenda item 9.3.3.
RAN1 to discuss SBFD aware UE behaviors in SBFD symbols with interaction with legacy TDD slot configuration indications via TDD-UL-DL-ConfigDedicated and SFI in DCI format 2_0
· DCI format 2_0 cannot be used to revert SBFD symbol to non-SBFD symbol
Agreement
For SBFD-aware UE transmission and reception in an SBFD symbol, consider the following options to determine link direction, i.e. whether to transmit or to receive in the SBFD symbol.
· Option 1: UE determines link direction based on configured/scheduled transmissions/receptions and collision handling (if any).
· Option 2: link direction is indicated by gNB explicitly.
Other options are not precluded.
Agreement
For SBFD-aware UEs, collisions between DL reception in DL subband(s) and UL transmission in UL subband in a SBFD symbol may be addressed or alleviated with proper scheduling. The following cases of potential collisions, [if link direction indication is not supported or provided], can be further studied to see if any change to the current specs is necessary:
Note: In addition to collision between UL transmission and DL reception in the same SBFD symbol(s), collision between UL transmission and DL reception in different symbol(s) due to lack of sufficient transition time between Tx/Rx at UE side is also included.
UE in RRC_IDLE/INACTIVE mode for random access is for study only until decision is made in RAN#104 to proceed to normative work.
R1-2401218 SBFD Random access operation Ericsson
· Proposal 1: RAN1 to consider whether existing PRACH configurations together with improved preamble detection methods may be used to increase cell range.
· Proposal 2: RAN1 to focus on enhancing the provided PRACH configuration instead of providing an additional complete PRACH configuration.
· Proposal 3: RAN1 to agree on one of the following objectives and specification approaches with SBFD PRACH:
o [Increasing coverage and/or range, by allowing longer PRACH formats in UL subbands and UL slots, or]
o Increase capacity and/or reduce latency, by introducing new RO validation rules in UL subbands for legacy PRACH.
· Proposal 4: RAN1 will not specify any new PRACH formats or configuration tables in Rel-19 SBFD.
· Proposal 5: Agree on whether or not long PRACH formats are supported.
· Proposal 6: The following design requirements for SBFD PRACH shall be followed:
o Legacy SSB-to-RO mapping must remain unchanged, and
o Legacy and SBFD ROs must not collide for different SSBs.
· Proposal 7: Introduce new validation rules such that ROs fully located within SBFD symbols and UL subband are valid for SBFD capable UEs.
· Proposal 8: Agree on whether to reuse the existing SSB-to-RO mapping or to configure an independent SSB-to-RO mapping for SBFD.
· Proposal 9: Further study the need for separate SBFD PRACH power control.
· Proposal 10: Await general work for PDSCH, PUSCH before specifying RA-specific behavior in Msg2, 3 and 4.
· Proposal 11: An SBFD UE transmitting a legacy preamble at a legacy RO continues to perform legacy RA.
· Proposal 12: RAN1 to await general SBFD PUSCH progress in AI 9.3.1 before specifying any RACH specific SBFD PUSCH enhancements.
Decision: The document is noted.
R1-2400054 Discussion on SBFD random access operation Spreadtrum Communications, BUPT
R1-2400109 On subband full duplex random access operation Huawei, HiSilicon
R1-2400153 Discussion for SBFD random access operation New H3C Technologies Co., Ltd.
R1-2400178 Discussion on SBFD Random Access Operation Tejas Network Limited
R1-2400242 Discussion on random access for Rel-19 SBFD vivo
R1-2400270 Discussion on SBFD random access operation TCL
R1-2400301 Discussion on SBFD random access operation ZTE
R1-2400326 Discussion on SBFD random access operation CMCC
R1-2400433 Discussion on SBFD random access operation CATT
R1-2400558 Discussion on SBFD random access operation xiaomi
R1-2400607 Discussion on SBFD random access operation OPPO
R1-2400651 Random access in SBFD symbols Sharp
R1-2400661 Discussion on SBFD random access operation China Telecom
R1-2400688 Discussion on enhancements for SBFD random access operations InterDigital, Inc.
R1-2400732 Random access on SBFD resources Samsung
R1-2400803 Discussion on random access for subband non-overlapping full duplex NEC
R1-2400827 Discussion on SBFD random access operation Panasonic
R1-2400839 SBFD random access operation Nokia, Nokia Shanghai Bell
R1-2400853 SBFD RACH operations Sony
R1-2400877 Discussion on Random Access for subband non-overlapping full duplex SK Telecom
R1-2401012 Views on SBFD random access operation Apple
R1-2401084 SBFD random access operation Lenono
R1-2401117 Discussion on SBFD random access operation NTT DOCOMO, INC.
R1-2401189 Discussion on SBFD operation to UE in RRC_IDLE/INACTIVE mode for random access ITRI
R1-2401192 Random access procedure for SBFD ASUSTeK
R1-2401210 Discussion on random access operation on SBFD symbols Fujitsu
R1-2401215 Discussion on SBFD random access operation WILUS
R1-2401228 SBFD random access operation ETRI
R1-2401250 Discussion on SBFD random access operation LG Electronics
R1-2401295 Discussion on SBFD random access operation MediaTek Inc.
R1-2401441 SBFD Random Access Operation Qualcomm Incorporated
R1-2401676 Summary#1 on SBFD random access operation Moderator (CMCC)
From Tuesday session
Working assumption:
For SBFD aware UEs in RRC CONNECTED state, support CBRA and CFRA in SBFD symbols.
Conclusion
No new PRACH format is introduced in Rel-19 duplex WI.
Agreement:
For random access operation for SBFD-aware UEs in RRC CONNECTED state, at least consider the following options:
· Option 1: Use one single RACH configuration with possible enhancement
o The ROs within UL subband in SBFD symbols can be valid for SBFD-aware UE
o FFS: Further details
· Option 2: Use two separate RACH configurations, including one legacy RACH configuration and one additional RACH configuration
o The ROs within UL subband in SBFD symbols configured by the additional RACH configuration can be valid for SBFD-aware UE
o FFS: Further details
Agreement:
For SBFD aware UEs in RRC CONNECTED state, support Type-1 random access procedure (4-step RACH) in SBFD symbols.
· FFS Type-2 random access procedure (2-step RACH)
R1-2401677 Summary#2 on SBFD random access operation Moderator (CMCC)
From Thursday session
Conclusion
If PRACH is allowed in SBFD symbols for SBFD-aware UEs in RRC_IDLE/INACTIVE mode, RAN1 observed the following:
For future meetings
Companies to consider whether the existing random access configuration tables for unpaired spectrum (i.e., Table 6.3.3.2-3 for FR1 and Table 6.3.3.2-4 for FR2) need to be enhanced.
Agreement
For SBFD aware UEs in RRC CONNECTED state, at least PRACH without repetition is supported in SBFD symbols.
R1-2401678 Summary#3 on SBFD random access operation Moderator (CMCC)
Agreement
For SBFD-aware UEs in RRC CONNECTED state, further study the following two options:
· Option 1: a valid RO can only be on SBFD symbols or on non-SBFD symbols
o a configured RO across SBFD and non-SBFD symbols in the same slot or across slots is invalid
· Option 2: a valid RO can be across SBFD and non-SBFD symbols in the same slot or across slots
RAN1 to leverage the study in Rel-18 as baseline.
Agreement
For SBFD-aware UEs in RRC CONNECTED state, at least further study whether/how to enable Msg2, Msg3 and Msg4 related transmission/reception in SBFD symbols taking into account the following aspects:
· Msg2[/Msg4 PDSCH] reception in DL subband(s)
· Msg3 PUSCH[/Msg4 HARQ-ACK PUCCH] frequency resource allocation and frequency hopping
· Msg3 repetition
· Msg3 PUSCH[/Msg4 HARQ-ACK PUCCH] power control
· FFS whether/how gNB to identify whether a UE is SBFD aware UE or non-SBFD aware UE
Note: Strive to make progress in accordance to the discussion in AI 9.3.1.
For future meetings
In RAN1#116bis meeting, at least the following issues will be discussed:
· Whether to support random access in SBFD symbols for UEs in RRC_IDLE/INACTIVE mode.
· Details of the two options for configuring ROs for SBFD aware UEs in RRC CONNECTED mode, including RO validation rules, SSB-RO mapping rules, whether/how to allow SBFD aware UE and non-SBFD aware UE to use different PRACH preamble formats.
· Whether/how to support separate PRACH power control parameters configuration in SBFD symbols and non-SBFD symbols.
· Whether/how to enhance the existing random access configuration tables for unpaired spectrum.
· Whether/how to support PRACH repetition.
R1-2400110 On cross-link interference handling for subband full duplex Huawei, HiSilicon
· Proposal 1: To facilitate effective down-selection, prioritize the CLI handling schemes with performance evaluations.
· Proposal 2: Support gNB-to-gNB channel measurement based beam nulling to suppress gNB-gNB co-channel CLI.
· Proposal 3: For gNB-to-gNB channel measurement, support information exchange of measure resource configuration between gNBs.
· Proposal 4: Support CSI-RS port expansion to facilitate gNB-to-gNB channel measurement, considering the following gNB-to-gNB channel characteristics to reduce the overhead of CSI-RS:
o gNB-to-gNB channel has a larger coherent time than gNB-UE channel.
o gNB-to-gNB channel has a larger coherent bandwidth than gNB-UE channel.
· Proposal 5: For gNB-to-gNB CLI measurement, support information exchange of measurement resource configuration, e.g., NZP CSI-RS, between gNBs.
· Proposal 6: Support non-transparent UL resource muting based scheme and introduce rate matching mechanism with RE symbol level granularity for PUSCH.
o SRS-like comb mapping pattern can be considered
· Proposal 7: Reducing DL Tx power will cause negative impact on DL performance, thus should be deprioritized.
· Proposal 8: Support L3 based UE-to-UE CLI measurement and reporting with some necessary enhancements and deprioritize L1/L2 based UE-to-UE CLI measurement and reporting.
· Proposal 9: Spatial domain coordination is deprioritized for UE-to-UE co-channel CLI handling.
Decision: The document is noted.
R1-2400055 Discussion on CLI handling Spreadtrum Communications
R1-2400156 Discussion on CLI handling New H3C Technologies Co., Ltd.
R1-2400179 Discussion on SBFD CLI Handling Tejas Network Limited
R1-2400243 Discussion on CLI handling for Rel-19 NR duplex vivo
R1-2400302 Discussion on CLI handling for Rel-19 duplex operation ZTE
R1-2400327 Discussion on CLI handling CMCC
R1-2400434 Discussion on CLI handling for NR duplex evolution CATT
R1-2400559 Discussion on CLI handling for SBFD operation xiaomi
R1-2400608 CLI handling in NR duplex operation OPPO
R1-2400689 Discussion on CLI handling for SBFD operations InterDigital, Inc.
R1-2400733 Cross-link interference handling for SBFD Samsung
R1-2400776 Discussion on CLI handling for SBFD operation Fujitsu
R1-2400804 CLI handling for NR duplex operation NEC
R1-2400828 Discussion on CLI handling Panasonic
R1-2400835 Cross-link interference management for duplexing evolution Lenovo
R1-2400840 Cross-link interference handling for duplex evolution Nokia, Nokia Shanghai Bell
R1-2400854 CLI handling for SBFD Sony
R1-2401013 Views on CLI handling Apple
R1-2401118 Discussion on CLI handling for sub-band full duplex (SBFD) NTT DOCOMO, INC.
R1-2401216 Discussion on CLI handling for evolution of NR duplex operation WILUS
R1-2401219 CLI handling Ericsson
R1-2401229 Discussion on CLI handling for SBFD operation ETRI
R1-2401246 On the gNB-to-gNB CLI and the UE-to-UE CLI handling Google Inc.
R1-2401251 Discussion on CLI handling LG Electronics
R1-2401274 Discussion on CLI handling CEWiT
R1-2401296 Discussion on CLI handling in SBFD MediaTek Inc.
R1-2401442 Enhancements for CLI handling Qualcomm Incorporated
R1-2401633 Summary #1 of CLI handling Moderator (Huawei)
From Tuesday session
Conclusion
For the down-selection of gNB-to-gNB co-channel CLI handling schemes and UE-to-UE co-channel CLI handling schemes, at least the following aspects should be considered:
Agreement
Consider the following candidate gNB-to-gNB co-channel CLI handling schemes for further down-selection
Note: gNB-to-gNB co-channel CLI and/or channel measurements can be the enablers for some of the above CLI handling schemes.
Agreement
Consider the following candidate UE-to-UE co-channel CLI handling schemes for further down-selection
· UE-to-UE co-channel CLI measurement and reporting
· Coordinated scheduling in time and/or frequency
· Spatial domain based schemes
· Power control based schemes
· Note: UE-to-UE co-channel CLI measurement and reporting can be the enablers for some of the above CLI handling schemes.
Agreement
gNB Tx power control based schemes are not considered in the down-selection of gNB-to-gNB co-channel CLI handling schemes.
R1-2401634 Summary #2 of CLI handling Moderator (Huawei)
From Thursday session
Agreement
For SBFD aware UEs, CLI measurements is performed within the active DL BWP and the following can be considered
Note: If DL subband, UL subband or guard band is outside the active DL BWP, the above methods does not apply.
Note: Method#4 does not imply that guard band is explicitly configured.
For future meetings
Companies are to refer to Proposal 2-2a (gNB-gNB CLI handling) and Proposal 3-2a (UE to UE CLI handling) in R1-2401635 for future meetings. Companies are encouraged to provide additional details on potential spec impact and operational details of their preferred CLI handling scheme for further down-selection in RAN1#116bis.
Final summary in R1-2401635.
Please refer to RP-240789 for detailed scope of the WI.
[116bis-R19-Duplex] – Xinghua (Huawei)
Email discussion on Rel-19 SBFD
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
Including semi-static indication of SBFD resources.
R1-2401980 Discussion on SBFD TX/RX/measurement procedures TCL
R1-2401994 On subband full duplex design Huawei, HiSilicon
R1-2402102 Discussion on SBFD TX/RX/measurement procedures Spreadtrum Communications
R1-2402124 On SBFD TX RX and measurement procedures InterDigital, Inc.
R1-2402165 Discussion on transmission, reception and measurement procedures for SBFD operation ZTE
R1-2402168 Discussion for SBFD TX RX measurement procedures New H3C Technologies Co., Ltd.
R1-2402239 Discussion on Rel-19 SBFD operation vivo
R1-2402325 Discussion on SBFD Tx/Rx/measurement procedures OPPO
R1-2402380 Discussion on SBFD TX/RX/measurement procedures CATT
R1-2402403 Discussion for SBFD TX/RX/ measurement procedures Tejas Network Limited
R1-2402463 SBFD operation and procedures Samsung
R1-2402508 Discussion on SBFD TX/RX/measurement procedures China Telecom
R1-2402532 Discussion on SBFD TX/RX/measurement procedures Langbo
R1-2402562 Discussion on SBFD TX/RX/measurement procedures CMCC
R1-2402595 Discussion on SBFD TX/RX/measurement procedures MediaTek Inc.
R1-2402663 Discussion on reception and transmission procedure for SBFD operation Xiaomi
R1-2402687 Discussion on SBFD operation Transsion Holdings
R1-2402795 Discussion on Tx/Rx/measurement procedures for SBFD operation Fujitsu
R1-2402803 SBFD TX/RX/measurement procedures Ericsson
R1-2402807 Discussion on SBFD TX/RX/measurement procedures ITRI
R1-2402817 Tx Rx procedure for SBFD ASUSTeK
R1-2402824 Discussion on subband non-overlapping full duplex Tx-Rx and measurement operations NEC
R1-2402878 Views on SBFD TX/RX/measurement procedures Apple
R1-2402910 Discussion on SBFD TX/RX/measurement procedures Panasonic
R1-2402925 On SBFD TX/RX/measurement procedures Nokia, Nokia Shanghai Bell
R1-2402964 SBFD operations Sony
R1-2403017 Discussion on SBFD TX/RX/measurement procedures ETRI
R1-2403057 Discussion on SBFD TX/RX/ measurement procedures CEWiT
R1-2403071 SBFD procedures in RRC_CONNECTED mode Sharp
R1-2403162 Views on SBFD TX/RX measurement procedures Lenovo
R1-2403191 SBFD Transmission, Reception and Measurement Procedures Qualcomm Incorporated
R1-2403215 Discussion on SBFD TX/RX/measurement procedures Google Inc.
R1-2403241 Discussion on SBFD TX/RX/measurement procedures NTT DOCOMO, INC.
R1-2403264 Discussion on SBFD TX/RX/measurement procedures LG Electronics
R1-2403307 Discussion on SBFD Tx/Rx/measurement procedures KT Corp.
R1-2403323 Discussions on SBFD TX/RX/measurement procedures Ruijie Networks Co. Ltd
R1-2403369 Discussion on SBFD TX/RX/measurement procedures WILUS
R1-2403377 Discussion on SBFD TX/RX operation CableLabs
R1-2403472 Summary #1 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Monday session
Agreement
A symbol configured as SBFD symbol via cell-specific configuration cannot be reverted to a non-SBFD symbol via any UE-specific configuration or group-common signaling.
A symbol not configured as SBFD symbol via cell-specific configuration cannot be reverted to an SBFD symbol via any UE-specific configuration or group-common signaling.
Agreement:
For frequency resource allocation Type 0 for PDSCH or PUSCH in a single slot by DCI based scheduling (without repetition or TBoMS), when an assigned RBG overlaps with the subband boundary, only the PRBs within DL usable PRBs are considered to be valid for PDSCH reception and only the PRBs within UL usable PRBs are considered to be valid for PUSCH transmission.
· SBFD aware UE does not expect to be assigned with a RBG for PDSCH which is fully outside DL usable PRBs or a RBG for PUSCH which is fully outside UL usable PRBs.
R1-2403473 Summary #2 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Wednesday session
Agreement
Study the feasibility and enhancements to support separate power control and/or spatial relation for SRS, PUCCH and PUSCH in SBFD and non-SBFD symbols in different slots, including repetition and non-repetition, by considering existing schemes, e.g. multi-TRP PUCCH/PUSCH repetition schemes.
Agreement
For frequency domain resource allocation Type 1 for PDSCH in a single slot scheduled at least by DCI format in USS, discuss and decide whether/which of the following options is supported.
Agreement
For cell-specific configuration of frequency locations of SBFD subbands,
· Option 1: Cell-specific frequency locations of SBFD subbands are separately configured for each SCS configuration in SCS-SpecificCarrierList.
o For each SCS configuration, the reference starting PRB is the PRB determined by the SCS configuration and offsetToCarrier corresponding to this subcarrier spacing.
Agreement
For an SPS PDSCH configuration without repetitions, if the reception occasions are across SBFD symbols and non-SBFD symbols where each reception occasion has either all SBFD or all non-SBFD symbols, discuss and decide whether/which of the following option(s) are supported.
For a CG PUSCH configuration without repetitions, if the transmission occasions are across SBFD symbols and non-SBFD symbols where each transmission occasion has either all SBFD or all non-SBFD symbols, discuss and decide whether/which of the following option(s) are supported.
R1-2403474 Summary #3 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Thursday session
Agreement
If link direction indication is not supported nor provided for a SBFD symbol, for collision Case 2 (semi-statically configured DL reception vs. dynamically scheduled UL transmission) in the SBFD symbol for SBFD-aware UEs, reuse the existing collision handling principles in NR for operation on flexible symbols on a single carrier in unpaired spectrum, i.e. UE does not receive DL channel/signal.
· The above does not imply link direction indication is supported
· FFS on dynamically scheduled UL transmission with repetition
Agreement
If link direction indication is not supported nor provided for a SBFD symbol, for collision Case 1 (dynamically scheduled DL reception vs. semi-statically configured UL transmission) in the SBFD symbol for SBFD-aware UEs, reuse the existing collision handling principles and timeline in NR for operation on flexible symbols on a single carrier in unpaired spectrum, i.e. UL transmission is cancelled if cancellation timeline is met.
· The above does not imply link direction indication is supported
· FFS on dynamically scheduled DL reception with repetition
Agreement
For
PDSCH repetitions across SBFD symbols and non-SBFD symbols in different slots
where each repetition has either all SBFD or all non-SBFD symbols, and for
multi-PDSCH scheduled by a single DCI across SBFD symbols and non-SBFD symbols in different slots, where each PDSCH within a slot
has either all SBFD or all non-SBFD symbols, discuss and decide whether/which
of the following option(s) are supported.
· Option 1: Separate FDRA configuration/indications/interpretations for SBFD symbols and non-SBFD symbols
· Option 2: Single FDRA configuration/indication for one symbol type (SBFD or non-SBFD symbol) and RB offset(s) configuration/indication/determination to determine resource for the other symbol type
· Option 3: A PDSCH in a slot overlapping with RBs outside DL usable PRBs in SBFD symbols is invalid, e.g. the PDSCH in the slot is dropped
· Option 4: Only PDSCH in one symbol type is valid and PDSCH in the other symbol type is invalid
· Option 5: For a PDSCH in a slot overlapping with RBs outside DL usable PRBs in SBFD symbols, only the assigned PRBs within DL usable PRBs are considered to be valid
· Option 6: gNB does not schedule any PDSCH in SBFD symbols in a slot to be overlapping with PRBs outside DL usable PRBs
· Other options are not precluded
· FFS: Applicable conditions
Agreement
For
PUSCH repetition type-A across SBFD symbols and non-SBFD symbols in different
slots where each repetition has either all SBFD or all non-SBFD symbols, and
for multi-PUSCH scheduled by a single DCI across SBFD symbols and non-SBFD
symbols in different slots, where each
PUSCH within a slot has either all SBFD or all non-SBFD symbols, and for TBoMS
across SBFD symbols and non-SBFD symbols in different slots, where each
transmission within a slot has either all SBFD or all non-SBFD symbols, discuss
and decide whether/which of the following option(s) are supported.
· Option 1: Separate FDRA configuration/indications/interpretations for SBFD symbols and non-SBFD symbols
· Option 2: Single FDRA configuration/indication for one symbol type (SBFD or non-SBFD symbol) and RB offset(s) configuration/indication/determination to determine resource for the other symbol type
· Option 3: A PUSCH in a slot overlapping with RBs outside UL usable PRBs in SBFD symbols is invalid, e.g. the PUSCH in the slot is dropped/postponed
· Option 4: Only PUSCH in one symbol type is valid and PUSCH in the other symbol type is invalid
· Option 5: For a PUSCH in a slot overlapping with RBs outside UL usable PRBs in SBFD symbols, only the assigned PRBs within UL usable PRBs are considered to be valid
· Option 6: gNB does not schedule any PUSCH in SBFD symbols in a slot to be overlapping with PRBs outside UL usable PRBs
· Other options are not precluded
· FFS: Applicable conditions
UE in RRC_IDLE/INACTIVE mode for random access is for study only until decision is made in RAN#104 to proceed to normative work.
R1-2401981 Discussion on SBFD random access operation TCL
R1-2401995 On subband full duplex random access operation Huawei, HiSilicon
R1-2402103 Discussion on SBFD random access operation Spreadtrum Communications, BUPT
R1-2402125 Enhancements on SBFD random access operations InterDigital, Inc.
R1-2402166 Discussion on SBFD random access operation ZTE
R1-2402169 Discussion for SBFD random access operation New H3C Technologies Co., Ltd.
R1-2402240 Discussion on random access for Rel-19 SBFD vivo
R1-2402326 Discussion on SBFD random access operation OPPO
R1-2402381 Discussion on SBFD random access operation CATT
R1-2402404 Discussion on SBFD Random Access Operation Tejas Network Limited
R1-2402464 Random access on SBFD resources Samsung
R1-2402509 Discussion on SBFD random access operation China Telecom
R1-2402533 Discussion on SBFD random access operation Langbo
R1-2402563 Discussion on SBFD random access operation CMCC
R1-2402596 Discussion on SBFD Random Access Operation MediaTek Inc.
R1-2402664 Discussion on SBFD random access operation Xiaomi
R1-2402688 Discussion on SBFD random access operation Transsion Holdings
R1-2402715 Discussion on SBFD random access operation Korea Testing Laboratory
R1-2402747 Discussion on SBFD for random access operation SK Telecom
R1-2402755 Discussion on random access for SBFD NEC
R1-2402808 Discussion on SBFD random access operation ITRI
R1-2402818 Random access procedure for SBFD ASUSTeK
R1-2402831 Discussion on SBFD random access operation Fujitsu
R1-2402879 Views on SBFD random access operation Apple
R1-2402911 Discussion on SBFD random access operation Panasonic
R1-2402926 SBFD random access operation Nokia, Nokia Shanghai Bell
R1-2402929 SBFD random access operation Lenovo
R1-2402965 SBFD RACH operation Sony
R1-2403018 SBFD random access operation ETRI
R1-2403072 Random access in SBFD symbols Sharp
R1-2403192 SBFD Random Access Operation Qualcomm Incorporated
R1-2403242 Discussion on SBFD random access operation NTT DOCOMO, INC.
R1-2403265 Discussion on SBFD random access operation LG Electronics
R1-2403332 On SBFD random access operation Google Inc.
R1-2403370 Discussion on SBFD random access operation WILUS
R1-2403468 Summary#1 on SBFD random access operation Moderator (CMCC)
From Monday session
Agreement
Confirm the working assumption:
Working assumption:
For SBFD aware UEs in RRC CONNECTED state, support CBRA and CFRA in SBFD symbols.
Agreement
For Option 1 (i.e., use one single RACH configuration with possible enhancement) to support random access operation for SBFD-aware UEs in RRC CONNECTED state, consider the following alternatives to derive the time and frequency resources of the configured ROs in SBFD symbols.
Agreement
For Option 1 (i.e., use one single RACH configuration with possible enhancement) to support random access operation for SBFD-aware UEs in RRC CONNECTED state, no separate prach-ConfigurationIndex to be configured in this option.
Agreement
For Option 1 (i.e., use one single RACH configuration with possible enhancement) to support random access operation for SBFD-aware UEs in RRC CONNECTED state, use existing random access configurations tables for unpaired spectrum (i.e., Table 6.3.3.2-3 for FR1 and Table 6.3.3.2-4 for FR2 in TS38.211).
Agreement
For Option 1 (i.e., use one single RACH configuration with possible enhancement) to support random access operation for SBFD-aware UEs in RRC CONNECTED state,
Note: For the case that all the SBFD symbols configured as downlink by tdd-UL-DL-ConfigurationCommon, there is no restriction that all the configured ROs in SBFD symbols should be within the UL usable PRBs.
R1-2403469 Summary#2 on SBFD random access operation Moderator (CMCC)
From Wednesday session
Working Assumption
For SBFD-aware UEs in RRC CONNECTED state, both RACH configuration Option 1 with Alt 1-1 (i.e., use one single RACH configuration, and only based on the existing parameters of the single RACH configuration) and RACH configuration Option 2 (i.e., Use two separate RACH configurations, including one legacy RACH configuration and one additional RACH configuration) are supported. Enabling both options at the same time for a UE is not supported.
UE is not required to support both options.
Agreement
For RACH configuration Option 2 (i.e., Use two separate RACH configurations, including one legacy RACH configuration and one additional RACH configuration) to support random access operation for SBFD-aware UEs in RRC CONNECTED state, down-select (in RAN1#117) from the following alternatives:
For the legacy-ROs configured by legacy RACH configuration, the legacy RO validation rules and the legacy SSB-RO mapping rules are followed for SBFD aware UEs.
Proposal
Support random access in SBFD symbols for UEs in RRC_IDLE/INACTIVE mode.
R1-2403437 SBFD Random access operation Ericsson (rev of R1-2402804)
R1-2403470 Summary#3 on SBFD random access operation Moderator (CMCC)
From Thursday session
Agreement
For SBFD-aware UEs in RRC CONNECTED state, and for RACH configuration Option 1 with Alt 1-1 (i.e., use one single RACH configuration, and only based on the existing parameters of the single RACH configuration),
· For the legacy-ROs, including the ROs in non-SBFD symbols and the ROs in SBFD symbols configured as flexible by tdd-UL-DL-ConfigurationCommon (if any), the legacy SSB-RO mapping is followed.
· For the ROs in SBFD symbols configured as downlink by tdd-UL-DL-ConfigurationCommon, separate SSB-RO mapping will be used
Agreement
For RACH configuration Option 2 (i.e., Use two separate RACH configurations, including one legacy RACH configuration and one additional RACH configuration) to support random access operation for SBFD-aware UEs in RRC CONNECTED state, and for interpretation of the parameter prach-ConfigurationIndex provided by the additional RACH configuration,
· For FR2, consider from the following alternatives:
o Alt 1: use existing random access configurations table for unpaired spectrum (i.e., Table 6.3.3.2-4 in TS38.211)
§ FFS whether to introduce new parameter(s) to determine the slot number for ROs in SBFD symbols.
o Alt 3: Introduce new entries on top of existing random access configurations table for unpaired spectrum (i.e., Table 6.3.3.2-4 in TS38.211)
· For FR1, consider from the following alternatives:
o Alt 1: Use existing random access configurations table for unpaired spectrum (i.e., Table 6.3.3.2-3 in TS38.211)
§ FFS whether to introduce new parameter(s) to determine the subframe number for ROs in SBFD symbols.
o Alt 2: Use existing random access configurations table for paired spectrum/supplementary uplink (i.e., Table 6.3.3.2-2 in TS38.211)
o Alt 3: Introduce new entries on top of existing random access configurations table for unpaired spectrum (i.e., Table 6.3.3.2-3 in TS38.211)
Final summary in R1-2403789.
R1-2401996 On cross-link interference handling for subband full duplex Huawei, HiSilicon
R1-2402104 Discussion on CLI handling Spreadtrum Communications
R1-2402126 On CLI handling for SBFD operations InterDigital, Inc.
R1-2402167 Discussion on CLI handling for Rel-19 duplex operation ZTE
R1-2402170 Discussion on CLI handling New H3C Technologies Co., Ltd.
R1-2402241 Discussion on CLI handling for Rel-19 NR duplex vivo
R1-2402327 CLI handling in NR duplex operation OPPO
R1-2402382 Discussion on CLI handling for NR duplex evolution CATT
R1-2402465 Cross-link interference handling for SBFD Samsung
R1-2402564 Discussion on CLI handling CMCC
R1-2402597 Discussion on CLI Handling in SBFD system MediaTek Inc.
R1-2402665 Discussion on CLI handling for SBFD operation Xiaomi
R1-2402689 Discussion on SBFD CLI handling Transsion Holdings
R1-2402751 Discussion on CLI handling Panasonic
R1-2402805 CLI handling Ericsson
R1-2402825 CLI handling for NR duplex operation NEC
R1-2402880 Views on CLI handling Apple
R1-2402923 Cross-link interference management for duplexing evolution Lenovo
R1-2402927 Cross-link interference handling for duplex evolution Nokia, Nokia Shanghai Bell
R1-2402966 CLI handling for SBFD Sony
R1-2403019 Discussion on CLI handling for SBFD operation ETRI
R1-2403044 Discussion on gNB-gNB CLI handling Tejas Network Limited
R1-2403046 Considerations and Recommendations for CLI mitigation for Subband Full Duplex Charter Communications, Inc
R1-2403058 Discussion on CLI handling CEWiT
R1-2403193 Enhancements for CLI handling Qualcomm Incorporated
R1-2403243 Discussion on CLI handling NTT DOCOMO, INC.
R1-2403266 Discussion on CLI handling LG Electronics
R1-2403330 On the gNB-to-gNB CLI and the UE-to-UE CLI handling Google Inc.
R1-2403371 Discussion on CLI handling for evolution of NR duplex operation WILUS
R1-2403512 Summary #1 of CLI handling Moderator (Huawei)
From Monday session
For future RAN1 meetings:
For the down-selection of gNB-to-gNB CLI handling scheme(s) and UE-to-UE CLI handling scheme(s), companies are encouraged to check whether the candidate co-channel CLI handling scheme can be applicable for inter-operator and/or intra-operator adjacent channel CLI handling.
· Note: Whether flexible symbol(s)/slot(s) with SBFD subband configurations can be convert into DL/UL symbols by TDD-UL-DL-ConfigDedicated is discussed under AI 9.3.1.
· Note: Whether UE-specific SBFD subband time domain location indication is supported is discussed under AI 9.3.1.
Agreement (updated as shown in red in Thursday session)
If beam nulling is supported for gNB-to-gNB CLI handling, the following are recommended to be specified
·
Information exchange of
measurement resource configuration, i.e., NCD-SSB and periodic NZP
CSI-RS.
·
[Information
exchange of CLI-mitigation request] à
Comeback on Wednesday
·
[Information
exchange of CLI-mitigation report] à
Comeback on Wednesday
Agreement
If beam pairing is supported for gNB-to-gNB CLI handling, the following are recommended to be specified
· Information exchange of measurement resource configuration, i.e., SSB and/or periodic NZP CSI-RS
· Information exchange of recommended/not-recommended DL beam information and associated resource configuration
R1-2403513 Summary #2 of CLI handling Moderator (Huawei)
From Wednesday session
Agreement
If non-transparent UL resource muting is supported for interference covariance matrix measurement for gNB-to-gNB CLI handling, the following are recommended to be specified
· Definition and indication of UL resource muting pattern
· Collision with DMRS/PTRS
· PUSCH resource mapping, i.e., rate-matching around the muted REs
· UCI resource determination
· Power allocation in symbols with muted REs considering potential impact to phase continuity
· TB size determination
Note: The existing reference signal time-frequency resource pattern, e.g., PT-RS, comb-2 SRS, are the candidates for the UL resource muting pattern.
Note: Consider pattern without adverse impact on PAPR
Note: The potential impact on transmit signal quality/MPR requirement may need to checked with RAN4.
Note: The above does not apply for PUSCH transmission during random access procedures.
Agreement
If non-transparent UL resource muting is supported for gNB-to-gNB CLI measurement for gNB-to-gNB CLI handling, the following are recommended to be specified
· Definition and indication of UL resource muting pattern
· Collision with DMRS/PTRS
· PUSCH resource mapping, i.e., rate-matching around the muted REs
· UCI resource determination
· Power allocation in symbols with muted REs considering potential impact to phase continuity
· TB size determination
· Exchange of information across gNBs on measurement resources
Note: The existing reference signal time-frequency resource pattern, e.g., CSI-RS, are used to determine the UL resource muting pattern.
Note: Consider pattern without adverse impact on PAPR
Note: The potential impact on transmit signal quality/MPR requirement may need to checked with RAN4.
Note: The above does not apply for PUSCH transmission during random access procedures.
Agreement
Consider the following alternatives for down selection in RAN1#117.
Alt.1:
If L1 based UE-to-UE CLI measurement and reporting based on existing CSI framework are supported for UE-to-UE CLI handling, the following are recommended to be specified
Alt.2:
If L1 based UE-to-UE CLI measurement and reporting based on existing CSI framework are supported for UE-to-UE CLI handling, the following are recommended to be specified
Alt.3:
If L1 based UE-to-UE CLI measurement and reporting based on existing CSI framework are supported for UE-to-UE CLI handling, the following are recommended to be specified
Note: The new measurements on CLI-IMR are included in the interference measurement term for the existing report quantities, i.e., CQI, L1-SINR.
Agreement
UL Tx power control based schemes are not considered in the down-selection of gNB-to-gNB CLI handling and UE-to-UE CLI handling schemes.
· Note: Support of UL Tx power control enhancements can be discussed in AI 9.3.1 and 9.3.2 (for PRACH only).
R1-2403514 Summary #3 of CLI handling Moderator (Huawei)
From Thursday session
Agreement
If coordinated scheduling in time and/or frequency is supported for gNB-to-gNB CLI handling and UE-to-UE CLI handling, the following is recommended to be specified
· Information exchange of semi-static cell-specific SBFD time and frequency location configuration
Conclusion
L1 based UE-to-UE CLI measurement and reporting based on event triggered based reporting are not considered for UE-to-UE CLI handling in Rel-19.
Please refer to RP-240789 for detailed scope of the WI.
[117-R19-Duplex] – Xinghua (Huawei)
Email discussion on Rel-19 SBFD
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
Including semi-static indication of SBFD resources.
R1-2403874 Discussion for SBFD TX/RX/ measurement procedures New H3C Technologies Co., Ltd.
R1-2403892 Discussion for SBFD TX/RX/ measurement procedures Tejas Networks Limited
R1-2403904 Discussion on SBFD TX/RX/measurement procedures LG Electronics
R1-2403911 SBFD Tx/Rx/measurement procedures Ericsson
R1-2403934 On subband full duplex design Huawei, HiSilicon
R1-2404007 Discussion on transmission, reception and measurement procedures for SBFD operation ZTE
R1-2404023 Discussion on SBFD TX/RX/measurement procedures Spreadtrum Communications
R1-2404047 Discussion on SBFD TX RX and measurement procedures InterDigital, Inc.
R1-2404057 Discussion on SBFD TX/RX/measurement procedures TCL
R1-2404112 SBFD operation and procedures Samsung
R1-2404174 Discussion on Rel-19 SBFD operation vivo
R1-2404281 Views on SBFD TX/RX/measurement procedures Apple
R1-2404317 SBFD procedures in RRC_CONNECTED mode Sharp
R1-2404348 Discussion on SBFD TX/RX/measurement procedures Google Inc.
R1-2404398 Discussion on SBFD TX/RX/measurement procedures CATT
R1-2404425 Discussion on SBFD TX/RX/measurement procedures China Telecom
R1-2404453 Discussion on SBFD TX/RX/measurement procedures CMCC
R1-2404497 SBFD Operations Sony
R1-2404516 Discussion on SBFD TX/RX/measurement procedures MediaTek Inc.
R1-2404591 Discussion on Tx/Rx/Measurement procedures for SBFD operation Fujitsu
R1-2404595 Discussion on SBFD TX/RX/measurement procedures Panasonic
R1-2404615 Discussion on reception and transmission procedure for SBFD operation Xiaomi
R1-2404732 Discussion on SBFD TX/RX/measurement procedures Langbo
R1-2404772 Discussion on SBFD TX/RX/measurement procedures ETRI
R1-2404792 Discussion on subband non-overlapping full duplex Tx-Rx and measurement operations NEC
R1-2404816 Discussion on SBFD operation Transsion Holdings
R1-2404865 Discussion on SBFD Tx/Rx/measurement procedures OPPO
R1-2404955 Views on SBFD TX/RX Measurement Procedures Lenovo
R1-2405039 Discussion on SBFD TX/RX/measurement procedures NTT DOCOMO, INC.
R1-2405060 On SBFD TX/RX/measurement procedures Nokia, Nokia Shanghai Bell
R1-2405112 Discussion on SBFD TX/RX/measurement procedures ITRI
R1-2405123 Discussions on SBFD TX/RX/measurement procedures Ruijie Networks Co. Ltd
R1-2405152 SBFD Transmission, Reception and Measurement Procedures Qualcomm Incorporated
R1-2405199 Tx Rx procedure for SBFD ASUSTeK
R1-2405240 Discussion on SBFD TX/RX/ measurement procedures CEWiT
R1-2405259 Discussion on SBFD Tx/Rx/measurement procedures KT Corp.
R1-2405280 Discussion on SBFD TX/RX/measurement procedures WILUS Inc.
R1-2405422 Summary #1 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Monday session
Agreement
For CSI report associated with periodic/semi-persistent CSI-RS, discuss and decide whether to support the following options.
Working Assumption
For frequency resource allocation for CSI-RS across downlink subbands for SBFD-aware UEs, support one contiguous CSI-RS resource allocation with non-contiguous CSI-RS resource derived by excluding frequency resources outside DL usable PRBs.
· No impact on CSI-RS sequence generation.
· CSI-RS sequence mapping is applied to CSI-RS resources within DL usable PRBs only (effectively, this is same as the case when the CSI-RS sequence mapped to the RBs outside the DL usable PRBs are punctured).
· RAN1 to further study the impact on CSI processing timeline in SBFD symbols to process the CSI-RS across the two DL subbands.
R1-2405423 Summary #2 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Tuesday session
Agreement
For a single TRP scenario, support separate UL power control for PUSCH/PUCCH/SRS transmissions in SBFD symbols and non-SBFD symbols
Agreement
For a contiguous CSI-RS resource which overlaps with SBFD subband boundaries, only CSI-RS frequency resources within DL usable PRBs are valid for SBFD-aware.
· No impact on CSI-RS sequence generation
· CSI-RS sequence mapping is applied to CSI-RS resources within DL usable PRBs only (effectively, this is same as the case when the CSI-RS sequence mapped to the RBs outside the DL usable PRBs are punctured)
Agreement
For a CSI reporting subband which overlaps with at least one PRB within DL usable PRBs and one or more PRBs outside DL usable PRBs, the CSI reporting subband includes PRB(s) within DL usable PRBs only.
Agreement
If link direction indication is not supported nor provided for a SBFD symbol, for collision Case 4 (dynamically scheduled DL reception vs. dynamically scheduled UL transmission) in a SBFD symbol for SBFD-aware UEs, it is considered as an error case if a dynamically scheduled DL reception in DL subband(s) without repetitions overlaps with a dynamically scheduled UL transmission in UL subband without repetitions.
Agreement
If link direction indication is not supported nor provided for a SBFD symbol, collision Case 3 (semi-statically configured DL reception vs. semi-statically configured UL transmission) in the SBFD symbol for SBFD-aware UEs is an error case.
Agreement
For UL transmissions and DL receptions across SBFD symbols and non-SBFD symbols in different slots (each transmission/reception within a slot has either all SBFD or all non-SBFD symbols) for an SBFD aware UE, the SBFD-aware UE is provided with one of the configurations.
· Configuration 1: The transmissions/receptions are restricted to SBFD symbols only or non-SBFD symbols only
· Configuration 2: The transmissions/receptions can be in SBFD symbols and non-SBFD symbols
· FFS granularity of the configuration, e.g. per UE, per channel/signal etc.
· FFS whether support of configuration 2 is subject to UE capability
R1-2405424 Summary #3 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Wednesday session
Agreement
For RRC connected mode UEs, SBFD subband time period:
· When only one TDD-UL-DL pattern is configured, the period is the same as TDD-UL-DL pattern period configured by dl-UL-TransmissionPeriodicity in TDD-UL-DL-ConfigCommon.
· When two TDD-UL-DL patterns are configured, the period is the same as the sum of the two TDD-UL-DL pattern periods configured by dl-UL-TransmissionPeriodicity in TDD-UL-DL-ConfigCommon.
Agreement
For cell-specific indication of SBFD subband frequency location, adopt the following option.
· Option 1: Frequency locations of UL subband and DL subband(s) are explicitly configured. Guardband(s) if any are implicitly derived as the RBs which are not within UL subband or DL subband(s).
Agreement (modified as shown in red in Thursday session)
For frequency domain resource allocation Type 1 for PDSCH in a single slot scheduled at least by DCI format in USS when PRG is determined as one of the values among {2, 4},
Agreement
Support separate FH offsets for PUSCH transmissions in SBFD symbols and non-SBFD symbols respectively.
· FFS: How to indicate/determine the FH offsets for PUSCH transmissions in SBFD and non-SBFD symbols, respectively.
· FFS: Whether/how to update FH calculation to only consider the UL usable PRBs
R1-2405425 Summary #4 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Thursday session
Agreement
For frequency resource allocation Type 0 for PDSCH or PUSCH in a single slot by DCI based scheduling (without repetition or TBoMS), when an assigned RBG overlaps with the subband boundary, the number of PRBs for TBS determination is based on the assigned PRBs within DL usable PRBs only and assigned PRBs within UL usable PRBs only for PDSCH and PUSCH respectively.
Agreement
Re-use the existing collision handling principles for NR TDD that SSB is prioritized over configured UL transmission and dynamically scheduled UL transmission
· FFS whether a slot consisting of SSB symbols is considered as a full DL slot or SSB symbols configured with SBFD subbands are SBFD symbols and only DL receptions within DL usable PRBs are allowed for SBFD aware UEs.
UE in RRC_IDLE/INACTIVE mode for random access is for study only until decision is made in RAN#104 to proceed to normative work.
R1-2403873 Discussion for SBFD random access operation New H3C Technologies Co., Ltd.
R1-2403893 Discussion on SBFD Random Access Operation Tejas Networks Limited
R1-2403905 Discussion on SBFD random access operation LG Electronics
R1-2403912 SBFD random access operation Ericsson
R1-2403935 On subband full duplex random access operation Huawei, HiSilicon
R1-2404008 Discussion on SBFD random access operation ZTE
R1-2404024 Discussion on SBFD random access operation Spreadtrum Communications, BUPT
R1-2404048 Discussion on SBFD random access operation InterDigital, Inc.
R1-2404056 Discussion on SBFD random access operation Korea Testing Laboratory
R1-2404058 Discussion on SBFD random access operation TCL
R1-2405349 Random access on SBFD resources Samsung (rev of R1-2404113)
R1-2404175 Discussion on random access for Rel-19 SBFD vivo
R1-2404282 Views on SBFD random access operation Apple
R1-2404318 Random access in SBFD symbols Sharp
R1-2404399 Discussion on SBFD random access operation CATT
R1-2404426 Discussion on SBFD random access operation China Telecom
R1-2404454 Discussion on SBFD random access operation CMCC
R1-2404498 SBFD PRACH Operations Sony
R1-2404517 Discussion on SBFD Random Access Operation MediaTek Inc.
R1-2404597 Discussion on SBFD random access operation Panasonic
R1-2404616 Discussion on SBFD random access operation Xiaomi
R1-2404661 Discussion on random access for SBFD NEC
R1-2404678 Discussion on SBFD for random access operation SK Telecom
R1-2404696 SBFD random access operation Lenovo
R1-2404733 Discussion on SBFD random access operation Langbo
R1-2404740 Discussion on SBFD random access operation Hyundai Motor Company
R1-2404773 SBFD random access operation ETRI
R1-2404804 Discussion on SBFD random access operation Fujitsu
R1-2404817 Discussion on SBFD random access operation Transsion Holdings
R1-2404866 Discussion on SBFD random access operation OPPO
R1-2404934 On SBFD random access operation Google Inc.
R1-2405040 Discussion on SBFD random access operation NTT DOCOMO, INC.
R1-2405061 SBFD random access operation Nokia, Nokia Shanghai Bell
R1-2405097 Discussion on SBFD Random Access operation KT Corp.
R1-2405113 Discussion on SBFD random access operation for SBFD aware UEs in RRC CONNECTED state ITRI
R1-2405153 SBFD Random Access Operation Qualcomm Incorporated
R1-2405200 Random access procedure for SBFD ASUSTeK
R1-2405281 Discussion on SBFD random access operation WILUS Inc.
R1-2405375 Summary#1 on SBFD random access operation Moderator (CMCC)
Presented in Monday session.
R1-2405376 Summary#2 on SBFD random access operation Moderator (CMCC)
R1-2405377 Summary#3 on SBFD random access operation Moderator (CMCC)
From Wednesday session
Agreement
A RO across SBFD symbols and non-SBFD symbols in the same slot or across slots is invalid by default.
A configured RO starting from SBFD symbol and ending in non-SBFD symbol either in the same slot or across different slots can be valid based on network configuration. This is only supported for RACH configuration option 2 and only supported for the ROs configured by the additional RACH configuration. If network configures such RO as a valid RO, UE should treat the RO as an additional-RO in SBFD symbols, and the followings are assumed by network and UE:
· The same frequency resources are used for both the SBFD segment and non-SBFD segment of the PRACH.
· The same UL transmit power is used for both the SBFD segment and non-SBFD segment of the PRACH.
· The same UL spatial domain filter is used for both the SBFD segment and non-SBFD segment of the PRACH.
· UE doesn’t stop PRACH transmission in the transition period/gap (if any) between SBFD and non-SBFD symbols
· There are no phase coherency requirements on the UE between the SBFD segment and non-SBFD segment of the PRACH.
· Other assumptions are not precluded.
NOTE: For FR2, network may need to ensure that the additional-RO and the legacy RO, which overlap with each other in time domain, are mapped to the same SSB.
Agreement
Support random access in SBFD symbols for UEs in RRC_IDLE/INACTIVE mode.
Agreement
Confirm the following working assumption.
Working Assumption
For SBFD-aware UEs in RRC CONNECTED state, both RACH configuration Option 1 with Alt 1-1 (i.e., use one single RACH configuration, and only based on the existing parameters of the single RACH configuration) and RACH configuration Option 2 (i.e., Use two separate RACH configurations, including one legacy RACH configuration and one additional RACH configuration) are supported. Enabling both options at the same time for a UE is not supported.
· For Option 1 with Alt 1-1, FFS whether/how to reinterpret msg1-FrequencyStart in rach-ConfigCommon, RO validation rules and SSB-RO mapping rules, etc.
· For Option 2, FFS the RO validation rules, SSB-RO mapping rules, whether all the parameters currently in rach-ConfigCommon are necessary to be included in the additional RACH configuration, etc.
UE is not required to support both options.
R1-2405656 Summary#4 on SBFD random access operation Moderator (CMCC)
From Thursday session
Conclusion
For SBFD-aware UEs in RRC CONNECTED state, and for RACH configuration Option 1 with Alt 1-1:
Agreement
For SBFD-aware UEs in RRC CONNECTED state, and for RACH configuration Option 1 with Alt 1-1, for the ROs in SBFD symbols configured as downlink by tdd-UL-DL-ConfigurationCommon, consider whether additional condition(s) on top of what was agreed in RAN1#116bis for RO validation are necessary. For example,
· Condition#1: A valid RO starts at least X>=0 (FFS the value) symbols after a last downlink non-SBFD symbol.
· Condition#2: A valid RO starts at least X>0 (FFS the value) symbols after the SSB.
· Condition#3: A valid RO does not precede a SSB in the PRACH slot.
Agreement
Update the following agreement made in RAN1#116-bis meeting:
For RACH configuration Option 2 (i.e., Use two separate RACH configurations, including one legacy RACH configuration and one additional RACH configuration) to support random access operation for SBFD-aware UEs in RRC CONNECTED state, and for interpretation of the parameter prach-ConfigurationIndex provided by the additional RACH configuration,
Final summary in R1-2405657.
R1-2403875 Discussion on CLI handling New H3C Technologies Co., Ltd.
R1-2403894 Discussion on gNB-gNB CLI handling Tejas Networks Limited
R1-2403906 Discussion on CLI handling LG Electronics
R1-2403913 SBFD CLI handling Ericsson
R1-2403936 On cross-link interference handling for subband full duplex Huawei, HiSilicon
R1-2404009 Discussion on CLI handling for Rel-19 duplex operation ZTE
R1-2404025 Discussion on CLI handling Spreadtrum Communications
R1-2404049 Discussion on CLI handling for SBFD operation InterDigital, Inc.
R1-2404114 Cross-link interference handling for SBFD Samsung
R1-2404176 Discussion on CLI handling for Rel-19 NR duplex vivo
R1-2404222 Aspects for further discussion on CLI Deutsche Telekom
R1-2404283 Views on CLI handling Apple
R1-2404400 Discussion on CLI handling for NR duplex evolution CATT
R1-2404455 Discussion on CLI handling CMCC
R1-2404499 CLI Handling for SBFD Sony
R1-2404518 Discussion on CLI Handling in SBFD system MediaTek Inc.
R1-2404530 Cross-link interference management for duplexing evolution Lenovo
R1-2404617 Discussion on CLI handling for SBFD operation Xiaomi
R1-2404662 CLI handling for NR duplex operations NEC
R1-2404726 Discussion on CLI handling Panasonic
R1-2404774 Discussion on CLI handling for SBFD operation ETRI
R1-2404818 Discussion on SBFD CLI handling Transsion Holdings
R1-2404867 CLI handling in NR duplex operation OPPO
R1-2404935 On the gNB-to-gNB CLI and the UE-to-UE CLI handling Google Inc.
R1-2405041 Discussion on CLI handling NTT DOCOMO, INC.
R1-2405062 Cross-link interference handling for duplex evolution Nokia, Nokia Shanghai Bell
R1-2405154 Enhancements for CLI handling Qualcomm Incorporated
R1-2405241 Discussion on CLI handling CEWiT
R1-2405282 Discussion on CLI handling for evolution of NR duplex operation WILUS Inc.
R1-2405468 Summary #1 of CLI handling Moderator (Huawei)
From Monday session
Agreement
Update the agreement in RAN1#116bis (changes mark in red) as follows
If beam nulling is supported for gNB-to-gNB CLI handling, the following are recommended to be specified
· Information exchange of measurement resource configuration, i.e., periodic NZP CSI-RS
· Information exchange of CLI-mitigation request.
· Note: No normative behavior is implied for the gNB receiving the CLI-mitigation request. No need to further send a stop message for CLI mitigation. Detailed signaling can be discussed in RAN3.
Agreement
If non-transparent UL resource muting is supported for gNB-to-gNB CLI handling, Option 1 is recommended to be specified
· Option 1: Comb-2 for both DFT-S-OFDM and CP-OFDM
· Note: Additional details can be discussed within RAN1#117.
· Note: Power boosting is assumed for REs in the symbol with UL resource muting. FFS: Details.
· Above is subject to separate UE capability (including separate capabilities for DFT-S-OFDM and CP-OFDM).
R1-2405469 Summary #2 of CLI handling Moderator (Huawei)
From Tuesday session
Agreement
If spatial domain-based schemes are supported for UE-to-UE CLI handling for FR2, the following are recommended to be specified
· Rx beams configuration for UE-to-UE CLI measurement
· Note: The above is subject to a separate optional UE capability.
Agreement
Agree the updated Alt.1 (changes in red) for L1 based UE-to-UE co-channel CLI measurement and reporting
Alt.1:
If L1 based UE-to-UE CLI measurement and reporting based on existing CSI framework are supported for UE-to-UE CLI handling, the following are recommended to be specified
· Measurement resources
o Periodic, semi-persistent, or aperiodic measurement resource (set) i.e., SRS-RSRP resource or CLI-RSSI resource
§ Note: The measurement resources for SRS-RSRP are based on the existing legacy RS patterns
o Rx beams configuration for UE-to-UE CLI measurement (if spatial domain coordination is supported)
· Measurement reporting
o Periodic,
semi-persistent or At least Aperiodic reporting on
PUSCH
§ Note: Periodic and semi-persistent reporting can be considered
§ Note: Aperiodic
reporting on PUCCH can be considered
o New report quantities: e.g. L1-SRS-RSRP, L1-CLI-RSSI and/or RS indexes
§ Note: At least wideband reporting is supported
o UCI bits generation
o UCI omission rule
o Priority rules for multiple CSI reporting
o CSI processing unit and CPU occupation rule
o Timeline and
related UE behaviours
o Note: The
existing UCI omission rule, CSI processing unit, CPU occupation rule and
timeline for L1 beam reporting are reused for L1 UE-to-UE CLI measurement and
reporting as starting point.
· CLI measurement accuracy requirement [RAN4]
Alt3 will not be considered in the downselection (i.e. only Alt 1 and Alt 2 will be considered)
R1-2405470 Summary #3 of CLI handling Moderator (Huawei)
Presented in Wednesday session.
R1-2405641 Summary #4 of CLI handling Moderator (Huawei)
From Thursday session
Agreement
For enhancements for CLI handling, the following are recommended from RAN1's perspective:
R1-2405641 Summary #4 of CLI handling Moderator (Huawei)
Please refer to RP-241614 for detailed scope of the WI.
[118-R19-Duplex] – Xinghua (Huawei)
Email discussion on Rel-19 SBFD
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
Including semi-static indication of SBFD resources.
R1-2405815 Discussion on SBFD TX/RX/measurement procedures MediaTek Inc.
R1-2405831 Discussion for SBFD TX RX measurement procedures New H3C Technologies Co., Ltd.
R1-2405847 On subband full duplex design Huawei, HiSilicon
R1-2405907 Discussion on SBFD TX/RX/measurement procedures Spreadtrum Communications
R1-2405933 Discussion on transmission, reception and measurement procedures for SBFD operation ZTE Corporation, Sanechips
R1-2405940 Discussion for SBFD TX/RX/ measurement procedures Tejas Networks Limited
R1-2405984 Discussion on SBFD TX/RX/measurement procedures CMCC
R1-2406059 Discussion on SBFD TX/RX/measurement procedures LG Electronics
R1-2406087 Discussion on SBFD TX/RX/measurement procedures China Telecom
R1-2406102 Discussion on SBFD TX/RX/measurement procedures TCL
R1-2406134 SBFD TX/RX/measurement procedures Ericsson
R1-2406181 Discussion on Rel-19 SBFD operation vivo
R1-2406209 Discussion on SBFD TX/RX/measurement procedures Kookmin University
R1-2406237 Discussion on SBFD Tx/Rx/measurement procedures OPPO
R1-2406283 Discussion on reception and transmission procedure for SBFD operation Xiaomi
R1-2406314 Discussion on Tx/Rx/measurement procedures for SBFD operation Fujitsu
R1-2406367 Discussion on SBFD TX/RX/measurement procedures CATT
R1-2406470 SBFD Operations Sony
R1-2406568 Discussion on SBFD TX/RX/measurement procedures Panasonic
R1-2406578 Discussion on SBFD TX/RX/measurement procedures HONOR
R1-2406596 Discussions on SBFD TX/RX/measurement procedures Ruijie Networks Co. Ltd
R1-2406598 Views on SBFD TX/RX Measurement Procedures Lenovo
R1-2406649 SBFD operation and procedures Samsung
R1-2406684 On SBFD TX/RX/measurement procedures Nokia, Nokia Shanghai Bell
R1-2406691 Discussion on subband non-overlapping full duplex Tx-Rx and measurement operations NEC
R1-2406702 Discussion on SBFD operation Transsion Holdings
R1-2406707 PRG allocation for SBFD ASUS
R1-2406725 Discussion on SBFD TX/RX/measurement procedures ETRI
R1-2406749 Discussion on TX RX and measurement procedures for SBFD operation InterDigital, Inc.
R1-2406800 SBFD Tx/Rx/measurement aspects Sharp
R1-2406835 Views on SBFD TX/RX/measurement procedures Apple
R1-2406929 Discussion on SBFD TX/RX/measurement procedures NTT DOCOMO, INC.
R1-2406963 Discussion on SBFD TX/RX/measurement procedures Google Ireland Limited
R1-2407028 SBFD Transmission, Reception and Measurement Procedures Qualcomm Incorporated
R1-2407067 Discussion on SBFD TX/RX/measurement procedures ITRI
R1-2407084 Discussion on SBFD TX/RX/measurement procedures CEWiT
R1-2407158 Discussion on SBFD TX/RX/measurement procedures WILUS Inc.
R1-2407218 Summary #1 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Tuesday session
Agreement
For configuration of SBFD symbols within a TDD-UL-DL pattern period, the following parameters are supported
· A starting slot index
· A starting symbol index within the starting slot
· An ending slot index
· An ending symbol index within the ending slot
Working Assumption
For
cell-specific configuration of frequency locations of SBFD UL subband, for each SCS
configuration in SCS-SpecificCarrierList for UL, starting RB and
bandwidth of SBFD UL subband are indicated by a RIV-based indication as defined
in 38.214 setting =275.
For
cell-specific configuration of frequency locations of SBFD DL subband(s), for each
SCS configuration in SCS-SpecificCarrierList for DL, starting RB and
bandwidth of each SBFD DL subband are indicated by a RIV-based indication as
defined in 38.214 setting =275.
· One or two SBFD DL subbands can be configured
Conclusion
If PRG is determined as wideband, UE does not expect to be scheduled with non-contiguous PRBs in SBFD symbols.
Agreement
For collision Case 1/2/4 with DL receptions and/or UL transmissions with repetitions, the same collision handling rules and timeline for DL receptions and UL transmissions without repetitions are applied for each repetition.
R1-2407219 Summary #2 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Wednesday session
Agreement
Support separate configurations of FH offsets for SBFD symbols and non-SBFD symbols, for a type 1 CG PUSCH with Configuration 2.
Support separate configurations of FH offset lists for SBFD symbols and non-SBFD symbols, for PUSCH scheduled by DCI and type 2 CG PUSCH.
UE applies the FH offset/FH offset list according to the symbol type of the PUSCH transmissions.
FFS UE behaviour when FH offset/FH offset list is not provided for SBFD symbols, e.g. FH is disabled for PUSCH transmissions in SBFD symbols, or FH offset/FH offset list for non-SBFD symbols are applied for SBFD symbols etc.
Agreement
Support separate frequency configurations for SBFD symbols and non-SBFD symbols in the same PUCCH-Resource.
FFS: UE behaviour when no separate configuration is provided for SBFD symbols, e.g. PUCCH transmissions in SBFD symbols for this pucch-ResourceId is not expected, or configurations for non-SBFD symbols are applied for SBFD symbols (in which case it is not expected that the configurations would lead to unexpected transmissions) etc.
Working Assumption
For an SPS PDSCH configuration without repetitions, if the reception occasions are across SBFD symbols and non-SBFD symbols where each reception occasion has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), PDSCH repetitions across SBFD symbols and non-SBFD symbols in different slots where each repetition has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), and for multi-PDSCH scheduled by a single DCI across SBFD symbols and non-SBFD symbols, where each PDSCH within a slot has either all SBFD or all non-SBFD symbols (i.e. Configuration 2),
R1-2407220 Summary #3 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Thursday session
Agreement
For Configuration 1: The transmissions/receptions are restricted to SBFD symbols only or non-SBFD symbols only, the valid symbol type is determined as following.
Agreement
For UL transmissions and DL receptions across SBFD symbols and non-SBFD symbols in different slots with Configuration 1,
· For PUSCH repetition type A with available slot counting, TBoMS and PUCCH repetitions, UE postpones transmissions in the invalid symbol type.
· For CG PUSCH and SPS PDSCH, P/SP SRS, P/SP CSI-RS, P/SP PUCCH, SP-CSI on PUSCH, PUSCH repetition type A without available slot counting, multi-PUSCH/PDSCH scheduled by a single DCI, and PDSCH repetitions, transmissions/receptions in the invalid symbol type are dropped.
Agreement
For a CG PUSCH configuration without repetitions, if the transmission occasions are across SBFD symbols and non-SBFD symbols where each transmission occasion has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), for PUSCH repetition type-A across SBFD symbols and non-SBFD symbols in different slots where each repetition has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), and for multi-PUSCH scheduled by a single DCI across SBFD symbols and non-SBFD symbols, where each PUSCH within a slot has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), and for TBoMS across SBFD symbols and non-SBFD symbols in different slots, where each transmission within a slot has either all SBFD or all non-SBFD symbols (i.e. Configuration 2),
Agreement
For a single TRP scenario, for separate UL power control for PUSCH/PUCCH/SRS transmissions in SBFD symbols and non-SBFD symbols based on unified TCI state framework, down-select from the following options to support separate configurations of UL power control parameters.
R1-2405816 Discussion on SBFD Random Access Operation MediaTek Inc.
R1-2405832 Discussion for SBFD random access operation New H3C Technologies Co., Ltd.
R1-2405848 On subband full duplex random access operation Huawei, HiSilicon
R1-2405908 Discussion on SBFD random access operation Spreadtrum Communications
R1-2405934 Discussion on SBFD random access operation ZTE Corporation, Sanechips
R1-2405941 Discussion on SBFD Random Access Operation Tejas Networks Limited
R1-2405985 Discussion on SBFD random access operation CMCC
R1-2406060 Discussion on SBFD random access operation LG Electronics
R1-2406088 Discussion on SBFD random access operation China Telecom
R1-2406103 Discussion on SBFD random access operation TCL
R1-2406106 Discussion on SBFD random access operation Korea Testing Laboratory
R1-2406135 SBFD Random access operation Ericsson
R1-2406182 Discussion on random access for Rel-19 SBFD vivo
R1-2406210 Discussion on SBFD random access operation Kookmin University
R1-2406238 Discussion on SBFD random access operation OPPO
R1-2406284 Discussion on SBFD random access operation Xiaomi
R1-2406368 Discussion on SBFD random access operation CATT
R1-2406471 SBFD PRACH Operations Sony
R1-2406514 Discussion on SBFD random access operation Fujitsu
R1-2406562 Discussion on random access for SBFD NEC
R1-2406569 Discussion on SBFD random access operation Panasonic
R1-2406575 Discussion on SBFD random access operation Hyundai Motor Company
R1-2406650 Random access on SBFD resources Samsung
R1-2406685 SBFD random access operation Nokia, Nokia Shanghai Bell
R1-2406688 SBFD random access operation Lenovo
R1-2406703 Discussion on SBFD random access operation Transsion Holdings
R1-2406726 SBFD random access operation ETRI
R1-2406750 On SBFD random access operation InterDigital, Inc.
R1-2406781 On SBFD random access operation Google Ireland Limited
R1-2406801 SBFD random access aspects Sharp
R1-2406836 Views on SBFD random access operation Apple
R1-2406886 Discussion on SBFD Random Access operation KT Corp.
R1-2406930 Discussion on SBFD random access operation NTT DOCOMO, INC.
R1-2407029 SBFD Random Access Operation Qualcomm Incorporated
R1-2407068 Discussion on SBFD random access operation for SBFD aware UEs in RRC CONNECTED state ITRI
R1-2407085 Discussion on SBFD random access operation CEWiT
R1-2407159 Discussion on SBFD random access operation WILUS Inc.
R1-2407228 Summary#1 on SBFD random access operation Moderator (CMCC)
From Tuesday session
Agreement
Extend the previous agreements for UEs in RRC_CONNECTED mode to UEs in RRC_IDLE/INACTIVE mode.
Agreement
For RAN1 discussion purpose, ‘additional-ROs’ is defined as the following:
· For RACH configuration Option 1, additional-ROs include the ROs in SBFD symbols configured as downlink by tdd-UL-DL-ConfigurationCommon, and the ROs across SBFD symbols configured as downlink and SBFD symbols configured as flexible by tdd-UL-DL-ConfigurationCommon.
· For RACH configuration Option 2, additional-ROs are the ROs configured by the additional RACH configuration.
Agreement
Regarding RO validation for RACH configuration Option 1 with Alt 1-1, an RO across SBFD symbols configured as downlink and SBFD symbols configured as flexible by tdd-UL-DL-ConfigurationCommon is treated the same as an RO in SBFD symbols configured as downlink by tdd-UL-DL-ConfigurationCommon.
· The RO includes at least one DL symbol configured by tdd-UL-DL-ConfigurationCommon
Agreement
For RACH configuration Option 1 with Alt 1-1, for determination of lowest RO of additional-ROs in SBFD symbols, select one from the following alternatives.
· Alt 1: The parameter msg1-FrequencyStart in rach-ConfigCommon is applied with no reinterpretation.
· Alt 2-1: The parameter msg1-FrequencyStart in rach-ConfigCommon is reinterpreted as the frequency offset of lowest RO in frequency domain with respective to the lowest PRB of UL usable PRBs.
· Alt 2-2: Use a fixed value (e.g., 0) for the frequency offset of lowest RO in frequency domain with respective to the lowest PRB of UL usable PRBs.
· Alt 2-3: The frequency offset of lowest RO in frequency domain with respective to the lowest PRB of UL usable PRBs is equal to mod (msg1-FrequencyStart, bandwidth of UL usable PRBs).
·
Alt 2-4: The frequency
offset of lowest RO in frequency domain with respective to the lowest PRB of UL
usable PRB is 
, where the 
.
· Note: Other alternatives are not precluded
Agreement (confirmed in Wednesday session)
For RACH configuration Option 1 with Alt 1-1, for the ROs in SBFD symbols configured as downlink by tdd-UL-DL-ConfigurationCommon, support the following conditions on top of what was agreed in RAN1#116bis for RO validation.
· Condition#1: A valid RO starts at least Ngap symbols after a last downlink non-SBFD symbol.
· Condition#2: A valid RO starts at least Ngap symbols after the SSB.
· Note: The Ngap here is the same as the Ngap in the current specification.
R1-2407229 Summary#2 on SBFD random access operation Moderator (CMCC)
From Wednesday session
Agreement
For RACH configuration Option 1 with Alt 1-1, the legacy SSB-RO mapping rule is reused for additional-ROs.
· FFS the association period and association pattern period.
Agreement
For SBFD aware UEs, at least support the following:
Note: SBFD aware UEs support PRACH transmission with preamble repetitions only within legacy-ROs (not across additional-ROs and legacy ROs) as in legacy releases.
Agreement (amended in Thursday session as shown in red)
For RACH configuration Option 2, and for interpretation of the parameter prach-ConfigurationIndex provided by the additional RACH configuration,
R1-2407230 Summary#3 on SBFD random access operation Moderator (CMCC)
From Thursday session
Agreement
For SBFD-aware UEs and RACH configuration Option 1 with Alt 1-1, consider the following options for initial PRACH transmission attempt in one random access procedure:
Agreement
For SBFD-aware UEs and RACH configuration Option 2, consider the following options for initial PRACH transmission attempt in one random access procedure:
Agreement
For SBFD aware UEs and RACH configuration Option 1 with Alt 1-1, consider the following options for PRACH transmission re-attempt in one random access procedure:
Agreement
For SBFD aware UEs and RACH configuration Option 2, consider the following options for PRACH transmission re-attempt in one random access procedure:
Agreement
For RACH configuration Option 2, support Alt 2-3 (the additional-ROs in non-SBFD symbols configured by additional RACH configuration are invalid for SBFD-aware UEs).
Working Assumption
For RACH configuration Option 2, use legacy SSB-RO mapping rule for the additional-ROs configured by the additional RACH configuration, separate from the SSB-RO mapping for the legacy-ROs configured by the legacy RACH configuration.
· FFS: Whether/How to handle the case where the legacy ROs overlap with additional ROs
R1-2405817 Discussion on CLI Handling in SBFD system MediaTek Inc.
R1-2405833 Discussion on CLI handling New H3C Technologies Co., Ltd.
R1-2405849 On cross-link interference handling for subband full duplex Huawei, HiSilicon
R1-2405909 Discussion on CLI handling Spreadtrum Communications
R1-2405935 Discussion on CLI handling for Rel-19 duplex operation ZTE Corporation, Sanechips
R1-2405942 Discussion on gNB-gNB CLI handling Tejas Networks Limited
R1-2405986 Discussion on CLI handling CMCC
R1-2406061 Discussion on CLI handling LG Electronics
R1-2406136 SBFD CLI handling Ericsson
R1-2406183 Discussion on CLI handling for Rel-19 NR duplex vivo
R1-2406239 CLI handling in NR duplex operation OPPO
R1-2406285 Discussion on CLI handling for SBFD operation Xiaomi
R1-2406369 Discussion on CLI handling for NR duplex evolution CATT
R1-2406472 CLI handling for SBFD Sony
R1-2406563 CLI handling for NR duplex operations NEC
R1-2406570 Discussion on CLI handling Panasonic
R1-2406651 Cross-link interference handling for SBFD Samsung
R1-2406686 Cross-link interference handling for duplex evolution Nokia, Nokia Shanghai Bell
R1-2406716 Further Considerations and Recommendations for CLI mitigation for Subband Full Duplex Charter Communications, Inc
R1-2406727 Discussion on CLI handling for SBFD operation ETRI
R1-2406751 On CLI handling for SBFD operation InterDigital, Inc.
R1-2406782 On the gNB-to-gNB CLI and the UE-to-UE CLI handling Google Ireland Limited
R1-2406837 Views on CLI handling Apple
R1-2406931 Discussion on CLI handling NTT DOCOMO, INC.
R1-2407030 Enhancements for CLI handling Qualcomm Incorporated
R1-2407062 Cross-link interference management for duplexing evolution Lenovo
R1-2407086 Discussion on CLI handling CEWiT
R1-2407160 Discussion on CLI handling for NR duplex operation WILUS Inc.
R1-2407353 Summary #1 of CLI handling Moderator (Huawei)
From Tuesday session
Agreement
For the time location configuration of UL resource muting for a PUSCH, one of the following options is selected
Note: Above has no implication on how UL muting symbol indication/determination is done.
Note: For both options, there will at most up to 2 UL muting symbols for the PUSCH.
Agreement
For the reference point of time location of UL resource muting for PUSCH, Option 1 is supported
· Option 1: Starting symbol of a slot for both PUSCH mapping type A and type B.
Agreement
Send an LS to RAN3 with the following information (cc: RAN2)
From RAN1
perspective, support information exchange among gNBs of measurement resource
configuration for both SSB and periodic NZP-CSI-RS.
From RAN1 perspective, exchange among
gNBs of the configuration info for a set of one or more periodic multi-port NZP CSI-RS resources (relevant IE in
38.331 are NZP-CSI-RS-Resource, NZP-CSI-RS-ResourceSet) is supported. Each resource in the set consist of P ports, where 1 ≤
P ≤ Pmax, and Pmax is the largest number of ports for a CSI-RS resource
supported in RAN1 specifications (128 in Rel-19).
Strongest DL beam information in the context of NZP-CSI-RS is defined as a CSI-RS Resource Indicator (CRI) value. CRI is a relative index in the range [1 .. N], where N is the number of CSI-RS resources within a set of resources for which the configuration is provided to a gNB.
Strongest DL beam information in the context of SSBs is defined as an SSB index. SSB index is an absolute index among the SSB(s) for which the configuration is provided to a gNB.
Note: RAN1 will not discuss information exchange among gNBs for gNB-gNB CLI handling unless there is an LS from RAN3.
Final LS is approved in:
R1-2407533 LS to RAN3 on PHY/L1 aspects of information exchange among gNBs for CLI mitigation RAN1, Ericsson
R1-2407354 Summary #2 of CLI handling Moderator (Huawei)
From Wednesday session
Agreement
For L1 UE-to-UE CLI measurement and reporting, CLI measurements is performed within the active DL BWP and the following are supported
· Method#1: UE measures RSSI within DL subband
· Method#2: UE measures RSRP of aggressor UE within UL subband
· FFS: Method#3: UE measures RSSI within UL subband
R1-2407355 Summary #3 of CLI handling Moderator (Huawei)
From Thursday session
Agreement
For frequency resource allocation of a CLI-RSSI measurement resource, the following are supported
· Measurement resource type#1: One CLI-RSSI measurement resource is configured within a DL subband
· Measurement resource type#2: One CLI-RSSI measurement resource is configured across two DL subbands
· FFS: Number of resources that can be configured
· FFS: UE behavior for measurement
Agreement
To determine the value
of k in 
for CSI reports carrying L1 UE-to-UE CLI
report, the following options are considered
· Option 1-1: Reusing existing k value, k = 0
· Option 1-2: Reusing existing k value, k = 1
· Option 2: Adding a new k value other than 0 and 1.
Agreement
For L1 UE-to-UE CLI measurement and reporting, the following are supported
· Wideband CLI-RSRP reporting
· Wideband CLI-RSSI reporting
· FFS: Subband CLI-RSSI reporting
Agreement
For L1 UE-to-UE CLI measurement and reporting, support two additional report quantities {‘cli-RSSI’, ‘cli-SRS-RSRP’} to the higher layer parameter reportQuantity.
· FFS: configuration of number of reported CLI resources in the reportConfig
· FFS: reporting criteria
Please refer to RP-241614 for detailed scope of the WI.
[118bis-R19-Duplex] – Xinghua (Huawei)
Email discussion on Rel-19 SBFD
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
Including semi-static indication of SBFD resources.
R1-2407624 Discussion for SBFD TX/RX/ measurement procedures New H3C Technologies Co., Ltd.
R1-2407631 Discussion on SBFD TX/RX/measurement procedures TCL
R1-2407675 On subband full duplex design Huawei, HiSilicon
R1-2407702 Discussion on SBFD TX/RX/measurement procedures Spreadtrum Communications
R1-2407730 Discussion on SBFD TX/RX/measurement procedures China Telecom
R1-2407752 Discussion for SBFD TX/RX/ measurement procedures Tejas Network Limited
R1-2407807 Discussion on transmission, reception and measurement procedures for SBFD operation ZTE Corporation, Sanechips
R1-2407857 Discussion on Rel-19 SBFD operation vivo
R1-2407901 Discussion on SBFD TX/RX/measurement procedures CMCC
R1-2407926 Discussion on SBFD TX/RX/measurement procedures MediaTek Inc
R1-2407965 Discussion on reception and transmission procedure for SBFD operation Xiaomi
R1-2408043 Discussion on SBFD TX/RX/measurement procedures CATT
R1-2408086 Discussion on SBFD TX/RX/measurement procedures LG Electronics
R1-2408112 Discussion on SBFD Tx/Rx/measurement procedures Fujitsu
R1-2408119 Discussion on SBFD operation Transsion Holdings
R1-2408142 Discussion on SBFD Tx/Rx/measurement procedures OPPO
R1-2408232 Discussion on SBFD TX-RX-measurement procedures HONOR
R1-2408276 On TX RX and measurement procedures for SBFD operation InterDigital, Inc.
R1-2408328 SBFD Tx/Rx/measurement aspects Sharp
R1-2408373 Discussion on subband non-overlapping full duplex Tx-Rx and measurement operations NEC
R1-2408383 Discussion on SBFD TX/RX/measurement procedures Ruijie Networks Co. Ltd
R1-2408407 SBFD Tx/Rx/Measurement Procedures Sony
R1-2408461 Discussion on SBFD TX/RX/measurement procedures Apple
R1-2408525 SBFD Tx/Rx/measurement procedures Ericsson
R1-2408530 Discussion on SBFD TX/RX/measurement procedures Panasonic
R1-2408551 Views on SBFD TX/RX Measurement Procedures Lenovo
R1-2408565 Discussion on SBFD TX/RX/measurement procedures ETRI
R1-2408593 On SBFD TX/RX/measurement procedures Nokia, Nokia Shanghai Bell
R1-2408600 Discussion on SBFD Tx/Rx/measurement procedures Fraunhofer HHI, Fraunhofer IIS
R1-2408642 SBFD operation and procedures Samsung
R1-2408782 Discussion on SBFD TX/RX/measurement procedures NTT DOCOMO, INC.
R1-2408825 Discussion on SBFD TX/RX/measurement procedures Kookmin University
R1-2408828 Discussion on SBFD TX/RX/measurement procedures ITRI
R1-2408846 SBFD Transmission, Reception and Measurement Procedures Qualcomm Incorporated
R1-2408879 Discussion on SBFD TX/RX/measurement procedures Google Ireland Limited
R1-2408898 Discussion on SBFD TX/RX/measurement procedures WILUS Inc.
R1-2408907 PRG allocation for SBFD ASUSTeK
R1-2408927 Discussion on SBFD TX/RX/ measurement procedures CEWiT
R1-2409086 Summary #1 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Tuesday session
Conclusion
Nominal RBG size for PDSCH/PUSCH in SBFD symbols is determined based on the size of DL/UL BWP as legacy. Nominal CSI reporting subband size in SBFD symbols is determined based on the size of DL BWP as legacy.
Agreement
If link direction indication is not supported nor provided for a SBFD symbol, for collision Case 6 (Dynamic or semi-static DL vs. valid RO), reuse the existing collision handling rules for HD-FDD RedCap UEs.
· UE does not expect collision between PRACH triggered by PDCCH order and dynamically scheduled DL reception.
· For collision between PRACH triggered by PDCCH order and semi-statically configured DL reception, UE does not receive DL channel/signal.
· For collision between PRACH triggered by higher layer and DL channel/signal, leave it to UE implementation whether to receive the DL or transmit PRACH.
Agreement
For CSI processing timeline in SBFD symbols to process the CSI-RS across two DL subbands,
Agreement
The number of configured FH offsets of FH offset list for SBFD symbols is the same as the number of FH offsets of FH offset list for non-SBFD symbols.
· The number of configured FH offsets of FH offset list is determined based on the UL BWP size as legacy.
The number of bits used to indicate FH offset in DCI is determined as legacy.
R1-2409087 Summary #2 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Wednesday session
Agreement
Support separate SRS configurations for SBFD and non-SBFD symbols. Select one from the following options.
Agreement
For a CSI report associated with periodic/semi-persistent CSI-RS, the valid symbol type for CSI derivation for periodic/semi-persistent CSI-RS resources for the CSI report is explicitly configured. Only CSI-RS transmission occasions within the valid symbol types are used for CSI derivation.
Agreement
For a PRG that overlaps the subband boundary, the part of the DL PRG inside the DL subband can be used subject to UE capability.
· UE capability reports the maximum number of supported partial PRGs in SBFD symbols.
Agreement
R1-2409088 Summary #3 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Thursday session
Agreement:
For PUSCH intra-slot frequency hopping in SBFD symbols, the starting RB in each hop is given by:
For
PUSCH inter-slot frequency hopping in SBFD symbols and when pusch-DMRS-Bundling is not enabled, or for
inter-slot frequency hopping for a PUSCH in SBFD symbols scheduled by RAR UL
grant or DCI format 0_0 with CRC scrambled by TC-RNTI, the starting RB during
slot 
is given by:
Where
is the starting
PRB index of UL usable PRBs with reference to the start of UL active BWP.
is the number of
UL usable PRBs.
is the starting
PRB index of the first PUSCH hop with reference to the start of UL active
BWP.
is unchanged from
existing specificationsDecide in RAN1#119, one of the following options:
in the above
equations
in the above
equations
Agreement:
For UL transmissions and DL receptions across SBFD symbols and non-SBFD symbols in different slots (each transmission/reception within a slot has either all SBFD or all non-SBFD symbols) for an SBFD aware UE, the SBFD-aware UE is provided with Configuration 1 or Configuration 2 via RRC configuration. Select from the following options
Agreement
At least in case when PUSCH frequency hopping is not enabled, for a CG PUSCH configuration without repetitions, if the transmission occasions are across SBFD symbols and non-SBFD symbols where each transmission occasion has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), for PUSCH repetition type-A across SBFD symbols and non-SBFD symbols in different slots where each repetition has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), and for multi-PUSCH scheduled by a single DCI across SBFD symbols and non-SBFD symbols, where each PUSCH within a slot has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), and for TBoMS across SBFD symbols and non-SBFD symbols in different slots,
are configured
and the starting PRB for PUSCH in SBFD symbol is determined according to
one of the following equation:
are not
precluded.
= round(
* 
) + 
is the starting
PRB index of PUSCH in SBFD symbol with reference to the start
of UL active BWP is the starting
PRB index of PUSCH in non-SBFD symbol with reference to the start
of UL active BWP
is the starting
PRB index of UL usable PRBs with reference to the start of UL active BWP
is the number of
PRBs of UL BWP
is the number of
PRBs of UL usable PRBs
is the number of
PRBs for PUSCH transmissions
in SBFD symbols. to be overlapped
with PRBs outside UL usable PRBs.
Working Assumption
For SSB symbols configured with SBFD subbands,
Agreement
If UE-specific configuration on frequency locations of SBFD subbands is not supported nor provided, support Option 1 for determining UL/DL usable PRBs.
· Option 1: For a UL BWP, UL usable PRBs are determined as intersection between cell-specific UL subband and the UL BWP in SBFD symbols. For a DL BWP, DL usable PRBs are determined as intersection between cell-specific DL subband(s) and the DL BWP in SBFD symbols.
Agreement
For a PDSCH/PUSCH with assigned PRBs overlapping with SBFD subband boundary and only the PRBs within DL/UL usable PRBs are valid for PDSCH/PUSCH reception/transmission, legacy DMRS sequence mapping is applied to assigned PRBs within DL/UL usable PRBs only (effectively, this is same as the case when the DMRS sequence mapped to the RBs outside the DL/UL usable PRBs are punctured).
Agreement
For configuration 1 and frequency resource allocation Type 0, if the valid symbol type for SPS PDSCH, CG PUSCH, PDSCH/PUSCH repetition, multi-PDSCH/PUSCH scheduled by a single DCI and TBoMS is SBFD symbols,
· When an assigned RBG overlaps with the subband boundary, only the PRBs within DL usable PRBs are considered to be valid for PDSCH reception and only the PRBs within UL usable PRBs are considered to be valid for PUSCH transmission.
· The number of PRBs for TBS determination is based on the assigned PRBs within DL usable PRBs only and assigned PRBs within UL usable PRBs only for PDSCH and PUSCH respectively.
· SBFD aware UE does not expect to be assigned with a RBG for PDSCH which is fully outside DL usable PRBs or a RBG for PUSCH which is fully outside UL usable PRBs.
· FFS: The above applies to SP-CSI on PUSCH when applicable
For configuration 1 and frequency resource allocation Type 1, if the valid symbol type for SPS PDSCH, PDSCH repetition and multi-PDSCH scheduled by a single DCI is SBFD symbols, then
· Only the assigned PRBs within DL usable PRBs are considered to be valid for PDSCH.
· Assigned PRBs that fall outside DL usable PRBs are considered to be invalid and should not be used for PDSCH resource mapping.
· Existing RB indexing and VRB-to-PRB mapping are reused.
· The number of PRBs for TBS determination is based on the assigned PRBs within DL usable PRBs only.
R1-2407625 Discussion for SBFD random access operation New H3C Technologies Co., Ltd.
R1-2407632 Discussion on SBFD random access operation TCL
R1-2407676 On subband full duplex random access operation Huawei, HiSilicon
R1-2407703 Discussion on SBFD random access operation Spreadtrum Communications
R1-2407731 Discussion on SBFD random access operation China Telecom
R1-2407753 Discussion on SBFD Random Access Operation Tejas Network Limited
R1-2407808 Discussion on SBFD random access operation ZTE Corporation, Sanechips
R1-2407858 Discussion on random access for Rel-19 SBFD vivo
R1-2407902 Discussion on SBFD random access operation CMCC
R1-2407927 Discussion on SBFD Random Access Operation MediaTek Inc
R1-2407966 Discussion on SBFD random access operation Xiaomi
R1-2408044 Discussion on SBFD random access operation CATT
R1-2408087 Discussion on SBFD random access operation LG Electronics
R1-2408115 Discussion on SBFD random access operation Korea Testing Laboratory
R1-2408120 Discussion on SBFD random access operation Transsion Holdings
R1-2408143 Discussion on SBFD random access operation OPPO
R1-2408215 Discussion on random access for SBFD NEC
R1-2408277 Discussion on SBFD random access operation InterDigital, Inc.
R1-2408325 SBFD random access operation Lenovo
R1-2408329 SBFD random access aspects Sharp
R1-2408384 Discussion on SBFD random access operation Ruijie Networks Co. Ltd
R1-2408408 SBFD RACH Operations Sony
R1-2408462 Views on SBFD random access operation Apple
R1-2408504 Discussion on SBFD random access operation Fujitsu
R1-2408526 SBFD random access operation Ericsson
R1-2408531 Discussion on SBFD random access operation Panasonic
R1-2408566 SBFD random access operation ETRI
R1-2408587 On SBFD random access operation Google Ireland Limited
R1-2408594 SBFD random access operation Nokia, Nokia Shanghai Bell
R1-2408643 Random access on SBFD resources Samsung
R1-2408752 Discussion on RO validation for SBFD aware UE ASUSTeK
R1-2408754 Discussion on SBFD Random Access operation KT Corp.
R1-2408783 Discussion on SBFD random access operation NTT DOCOMO, INC.
R1-2408826 Discussion on SBFD random access operation Kookmin University
R1-2408829 Discussion on SBFD random access operation for SBFD aware UEs ITRI
R1-2408847 SBFD Random Access Operation Qualcomm Incorporated
R1-2408899 Discussion on SBFD random access operation WILUS Inc.
R1-2408928 Discussion on SBFD random access operation CEWiT
R1-2409046 Summary#1 on SBFD random access operation Moderator (CMCC)
From Tuesday session
Agreement
For RACH configuration Option 1 with Alt 1-1, the association period and association pattern period of additional-ROs are determined separately from legacy-ROs.
· The legacy rules for determining association period and association pattern period are reused in principle for additional-ROs.
Agreement
For RACH configuration Option 2, an additional-RO is valid if:
· It is within SBFD symbols, or network configures that it can be valid if it starts from SBFD symbol and ends in non-SBFD symbol either in the same slot or across different slots.
· It starts at least Ngap symbols after a last downlink non-SBFD symbol.
· It starts at least Ngap symbols after the latest SSB
· It does not overlap with SSB in time domain
Note1: The Ngap here is the same as the Ngap in the current specification.
Note2: It is up to network to ensure an additional-RO is configured within the bandwidth of the UL usable PRBs.
Agreement
Confirm the following Working Assumption:
Working Assumption
For RACH configuration Option 2, use legacy SSB-RO mapping rule for the additional-ROs configured by the additional RACH configuration, separate from the SSB-RO mapping for the legacy-ROs configured by the legacy RACH configuration.
· FFS: Whether/How to handle the case where the legacy ROs overlap with additional ROs
Agreement
Confirm the following working assumption.
Agreement
For RACH configuration Option 2, and for interpretation of the parameter prach-ConfigurationIndex provided by the additional RACH configuration,
· For FR2, use existing random access configurations table for unpaired spectrum (i.e., Table 6.3.3.2-4 in TS38.211)
o FFS whether to introduce new parameter(s) to determine the slot number for ROs in SBFD symbols.
· Working Assumption: For FR1, use existing random access configurations table for unpaired spectrum (i.e., Table 6.3.3.2-3 in TS38.211)
o FFS whether to introduce new parameter(s) to determine the subframe number for ROs in SBFD symbols.
Agreement
For RACH configuration Option 1, support separate power control parameters for PRACH transmission in SBFD symbols and non-SBFD symbols
· FFS: Details of the separate power control parameters
R1-2409047 Summary#2 on SBFD random access operation Moderator (CMCC)
From Wednesday session
Conclusion
There is no consensus in RAN1 to support preamble partitioning on legacy-ROs for early indication of SBFD-aware UEs. It’s up to RAN2 to decide whether to support preamble partitioning on legacy-ROs for early indication of SBFD-aware UEs.
Working Assumption
For
a PRACH transmission with 
preamble repetition
within additional-ROs, support reusing current specification rules for the
determination of the set of valid additional-ROs
and the time period
of the set(s) of valid additional-ROs.
·
The time period of the set(s) of valid
additional-ROs is determined separately from the time period for legacy-ROs.
Conclusion
PRACH transmission with preamble repetitions across additional-ROs and legacy-ROs is not supported.
Agreement
For SBFD-aware UEs and PRACH mask indication for CFRA triggered by PDCCH order, discuss whether/how to indicate/determine additional-RO only, legacy-RO only, or both is used.
Agreement
For SBFD aware UEs, for Msg3 PUSCH transmission, reuse Table 8.3-1 in TS 38.213 for determination of the frequency offset for the 2nd hop, with the update that the frequency offset for 2nd hop is based on the size of UL usable PRBs.
·
FFS the case when the value of 
= 11
· FFS the definition of UL usable PRBs for Msg3 PUSCH transmission
Agreement
For RACH configuration Option 1 with Alt 1-1, for determination of lowest RO of additional-ROs in SBFD symbols, select one from the following alternatives.
· Alt 1: The parameter msg1-FrequencyStart in rach-ConfigCommon is applied with no reinterpretation.
· Alt 2-1: The parameter msg1-FrequencyStart in rach-ConfigCommon is reinterpreted as the frequency offset of lowest RO in frequency domain with respective to the lowest PRB of UL usable PRBs.
· Alt 2-3: The frequency offset of lowest RO in frequency domain with respective to the lowest PRB of UL usable PRBs is equal to mod (msg1-FrequencyStart, bandwidth of UL usable PRBs).
· FFS: Possible modifications
Conclusion
There is no consensus in RAN1 to support the following in Rel-19:
· Enabling both RACH configuration Option 1 and Option 2 for SBFD random access operation in a cell from network side.
R1-2407626 Discussion on CLI handling New H3C Technologies Co., Ltd.
R1-2407677 On cross-link interference handling for subband full duplex Huawei, HiSilicon
R1-2407704 Discussion on CLI handling Spreadtrum Communications
R1-2407754 Discussion on gNB-gNB CLI handling Tejas Network Limited
R1-2407809 Discussion on CLI handling for Rel-19 duplex operation ZTE Corporation, Sanechips
R1-2407859 Discussion on CLI handling for Rel-19 NR duplex vivo
R1-2407903 Discussion on CLI handling CMCC
R1-2407928 Discussion on CLI Handling in SBFD System MediaTek Inc
R1-2407967 Discussion on CLI handling for SBFD operation Xiaomi
R1-2408045 Discussion on CLI handling for NR duplex evolution CATT
R1-2408088 Discussion on CLI handling LG Electronics
R1-2408144 CLI handling in NR duplex operation OPPO
R1-2408216 CLI handling for NR duplex operations NEC
R1-2408278 Discussion on CLI handling for SBFD operation InterDigital, Inc.
R1-2408409 CLI handling for SBFD Sony
R1-2408463 Discussion on CLI handling Apple
R1-2408498 Discussion on CLI handling Panasonic
R1-2408527 SBFD CLI Handling Ericsson
R1-2408567 Discussion on CLI handling for SBFD operation ETRI
R1-2408588 On the gNB-to-gNB CLI and the UE-to-UE CLI handling Google Ireland Limited
R1-2408595 Cross-link interference handling for duplex evolution Nokia, Nokia Shanghai Bell
R1-2408644 Cross-link interference handling for SBFD Samsung
R1-2408784 Discussion on CLI handling NTT DOCOMO, INC.
R1-2408848 Enhancements for CLI handling Qualcomm Incorporated
R1-2408884 Cross-link interference management for duplexing evolution Lenovo
R1-2408929 Discussion on CLI handling CEWiT
R1-2409175 Summary #1 of CLI handling Moderator (Huawei)
From Tuesday session
Agreement
Extend CSI-ResourceConfig to include two CLI measurement resource set lists for SRS-RSRP and CLI-RSSI measurements based on Rel-16 SRS-ResourceConfigCLI and rssi-ResourceConfigCLI defined in MeasObjectCLI for L3 based SRS-RSRP and CLI-RSSI measurement.
· The resourceType for the two new CLI measurement resource set lists can be set to periodic, semi-persistent or aperiodic
· Note: No new usage needs to be defined for SRS resource sets
Agreement
For aperiodic SRS-RSRP reporting using aperiodic SRS-RSRP measurement resource set, the slot offset between the slot containing the DCI that triggers a set of aperiodic SRS-RSRP resources and the slot in which the SRS-RSRP resource set is measured is configured by higher layer parameter.
· FFS: Whether to reuse the legacy SRS resource set
· FFS: Whether available slot offset list is also reused
For aperiodic CLI-RSSP reporting using aperiodic CLI-RSSI measurement resource set, the slot offset between the slot containing the DCI that triggers a set of aperiodic CLI-RSSI resources and the slot in which the CLI-RSSI resource set is measured is configured by higher layer parameter.
R1-2409176 Summary #2 of CLI handling Moderator (Huawei)
From Wednesday session
Agreement
To determine the time location of UL muting symbol(s) in a slot for a PUSCH, one of the following options is selected for DG PUSCH and Type 2 CG PUSCH
· Option 1: The time location of each of one or two UL muting symbols is semi-statically configured and cannot be dynamically indicated
· Option 2: The time location of each of one or two UL muting symbols is semi-statically configured, and muting all of the semi-statically configured time location of UL muting symbol(s) can be dynamically turned ON/OFF by TDRA field in DCI
· Option 3: The time location of each of one or more UL muting symbols is semi-statically configured, and none, one or two the time location of UL muting symbol(s) is dynamically indicated by TDRA field in DCI
To determine the time location of UL muting symbol(s) in a slot for a PUSCH, the time location of each of one or two UL muting symbols is semi-statically configured for Type 1 CG PUSCH.
FFS: details of semi-static configuration and dynamic indication (if supported).
FFS: how to handle UL resource muting for PUSCH repetition and for multi-PUSCH scheduled by a single DCI.
Agreement
If UL resource muting is applied on a symbol for a PUSCH, a comb-2 pattern is applied for all of the allocated PRBs of the PUSCH on that symbol.
Agreement
For UCI rate matching, to determine the number of coded modulation symbols per layer for UCI transmission on PUSCH, the following option is adopted
·
Option 2: The number of
coded modulation symbols per layer for UCI on PUSCH is calculated based on 
after excluding the UL muting resource.
Working Assumption
UL resource muting is allowed on PUSCH symbols that carry UCI, i.e., UCI is not mapped on muted REs
Note: As mentioned in the WID, no specification changes are allowed on data and control multiplexing in section 6.2.7, TS 38.212.
Agreement
For Method#1 (RSSI measurement within DL subband), the frequency resources of CLI-RSSI measurement resource type#2 (One CLI-RSSI measurement resource across two DL subbands) is derived by excluding the frequency resources outside DL usable PRBs.
· A single wideband RSSI measurement report is supported.
· FFS: two per-DL-subband CLI-RSSI measurements reports with wideband report in each DL-subband.
Agreement
For aperiodic CLI reporting on PUSCH
· Reuse CSI-AperiodicTriggerStateList to configure the trigger state associated with one or more aperiodic CSI-ReportConfig.
· Reuse the existing DCI field 'CSI request' to trigger an aperiodic CLI report.
· Introduce an indication in CSI-AssociatedReportConfigInfo that selects a set from the list of CLI-RSSI measurement resource sets or SRS-RSRP measurement resource sets configured in CSI-ResourceConfig.
Agreement
For L1 CLI-RSSI measurement, DL timing is used for Method #1 (UE measures RSSI within DL subband).
R1-2409177 Summary #3 of CLI handling Moderator (Huawei)
From Thursday session
Agreement
In CSI-ReportConfig, reuse resourcesForChannelMeasurement providing the ID of a CSI-ResourceConfig that contains configuration of measurement resources for L1-SRS-RSRP and/or L1-CLI-RSSI.
Agreement
For aperiodic L1 CLI-RSSI/CLI-SRS-RSRP reporting on PUSCH, support the following in the IE CSI-AperiodicTriggerStateList:
FFS: details of configuration of TCI state(s) for aperiodic reporting based on periodic and semi-persistent CLI measurement resources
Agreement
Update previous agreement as follows (update in red).
Agreement
Extend CSI-ResourceConfig to include two CLI measurement resource set lists for SRS-RSRP and CLI-RSSI measurements based on Rel-16 SRS-ResourceConfigCLI and rssi-ResourceConfigCLI defined in MeasObjectCLI for L3 based SRS-RSRP and CLI-RSSI measurement.
· The resourceType for the two new CLI measurement resource set lists can be set to periodic, semi-persistent or aperiodic
· The number of periodic/semi-persistent CLI measurement resource sets is restricted to 1 in a CSI-ResourceConfig as in current specifications.
· Note: No new usage needs to be defined for SRS resource sets
Agreement
Update the following agreement
Agreement
For aperiodic CLI reporting on PUSCH
· Reuse CSI-AperiodicTriggerStateList to configure the trigger state associated with one or more aperiodic CSI-ReportConfig
· Reuse the existing DCI field 'CSI request' to trigger an aperiodic CLI report
· Introduce an indication in CSI-AssociatedReportConfigInfo that selects a set from the list of CLI-RSSI measurement resource sets or SRS-RSRP measurement resource sets configured in CSI-ResourceConfig
· Note: As in current specifications, the parameter for indication (e.g., resourceSet) is always present, but only used in the case that the CSI-ResourceConfig is configured with multiple sets of aperiodic CLI measurement resources.
Agreement
Alt
2: To determine the value of k in 
for CSI
reports carrying L1 UE-to-UE CLI report, the following options is adopted
· Option 1-2: Reusing existing k value, k = 1
Please refer to RP-241614 for detailed scope of the WI.
[119-R19-Duplex] – Xinghua (Huawei)
Email discussion on Rel-19 SBFD
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
Including semi-static indication of SBFD resources.
R1-2409374 Discussion for SBFD TX/RX/ measurement procedures New H3C Technologies Co., Ltd.
R1-2409410 On subband full duplex design Huawei, HiSilicon
R1-2409452 Discussion on SBFD TX/RX/measurement procedures MediaTek Inc.
R1-2409474 Discussion on SBFD TX/RX/measurement procedures TCL
R1-2409488 Discussion on SBFD TX/RX/measurement procedures LG Electronics
R1-2409508 Discussion on SBFD TX/RX/measurement procedures CMCC
R1-2409538 Discussion on transmission, reception and measurement procedures for SBFD operation ZTE Corporation, Sanechips
R1-2409566 Discussion on SBFD TX_RX_measurement procedures InterDigital, Inc.
R1-2409593 SBFD operation and procedures Samsung
R1-2409632 Discussion on SBFD TX/RX/measurement procedures Spreadtrum, UNISOC
R1-2409677 Discussion on Rel-19 SBFD operation vivo
R1-2409763 Discussion for SBFD TX/RX/ measurement procedures Tejas Networks Limited
R1-2409796 Discussion on SBFD TX/RX/measurement procedures Apple
R1-2409843 Discussion on SBFD TX/RX/measurement procedures Ruijie Networks Co. Ltd
R1-2409892 Discussion on reception and transmission procedure for SBFD operation Xiaomi
R1-2409937 Discussion on SBFD TX/RX/measurement procedures CATT
R1-2409963 Discussion on SBFD operation Transsion Holdings
R1-2409998 Discussion on SBFD TX/RX/measurement procedures China Telecom
R1-2410045 Discussion on SBFD TX/RX/measurement procedures Panasonic
R1-2410057 Discussion on SBFD Tx/Rx/measurement procedures Fujitsu
R1-2410086 Discussion on SBFD Tx/Rx/measurement procedures OPPO
R1-2410137 On SBFD TX/RX/measurement procedures Nokia, Nokia Shanghai Bell
R1-2410140 SBFD TX/RX/measurement procedures Ericsson
R1-2410177 Discussion on SBFD TX/RX/measurement procedures HONOR
R1-2410191 Views on SBFD TX/RX Measurement Procedures Lenovo
R1-2410206 Discussion on subband non-overlapping full duplex Tx-Rx and measurement operations NEC
R1-2410222 SBFD Procedures Sony
R1-2410241 Discussion on SBFD Tx/Rx/measurement procedures Fraunhofer HHI, Fraunhofer IIS
R1-2410264 Discussion on SBFD TX/RX/measurement procedures ETRI
R1-2410385 Discussion on SBFD TX/RX/measurement procedures NTT DOCOMO, INC.
R1-2410410 SBFD Tx/Rx/measurement aspects Sharp
R1-2410428 Discussion on SBFD TX/RX/measurement procedures ITRI
R1-2410474 SBFD Transmission, Reception and Measurement Procedures Qualcomm Incorporated
R1-2410545 Discussion on SBFD TX/RX/measurement procedures Google Ireland Limited
R1-2410548 Partial PRG handling for SBFD ASUSTeK
R1-2410558 Discussion on SBFD TX/RX/measurement procedures WILUS Inc.
R1-2410574 Discussion on SBFD TX/RX/ measurement procedures CEWiT
R1-2410692 Summary #1 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Tuesday session
Agreement
For
a physical channel/signal occasion mapped
to SBFD and non-SBFD symbols within a slot, an SBFD aware UE does not transmit or
receive the physical channel/signal within the slot., except
R1-2410693 Summary #2 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Wednesday session
Agreement
Confirm the following working assumption made in RAN1#118.
Working Assumption
For cell-specific configuration of
frequency locations of SBFD UL subband, for each SCS configuration in SCS-SpecificCarrierList for UL,
starting RB and bandwidth of SBFD UL subband are indicated by a RIV-based
indication as defined in 38.214 setting 
=275.
For cell-specific configuration of
frequency locations of SBFD DL subband(s), for each SCS configuration in SCS-SpecificCarrierList for DL,
starting RB and bandwidth of each SBFD DL subband are indicated by a RIV-based
indication as defined in 38.214 setting =275.
· One or two SBFD DL subbands can be configured
Agreement
For configuration 1 and frequency resource allocation Type 0, if the valid symbol type for SP-CSI on PUSCH is SBFD symbols,
· When an assigned RBG overlaps with the subband boundary, only the PRBs within UL usable PRBs are considered to be valid for PUSCH transmission.
· SBFD aware UE does not expect to be assigned with a RBG for PUSCH which is fully outside UL usable PRBs.
Agreement
Update the following agreement made in RAN1#118 meeting:
Agreement
For UL transmissions and DL receptions across SBFD symbols and non-SBFD symbols in different slots (each transmission/reception within a slot has either all SBFD or all non-SBFD symbols) with Configuration 1,
· For PUSCH repetition type A with available slot counting, A-SRS with available slot counting, TBoMS and PUCCH repetitions, UE postpones transmissions in the invalid symbol type.
·
For CG PUSCH with
neither TBoMS nor PUSCH repetition type A with available slot counting,and
SPS PDSCH, P/SP SRS, P/SP CSI-RS, P/SP PUCCH, SP-CSI on PUSCH, PUSCH repetition
type A without available slot counting, multi-PUSCH/PDSCH scheduled by a single
DCI, and PDSCH repetitions, transmissions/receptions in the invalid symbol type
are dropped.
Agreement
Update the following agreement made in RAN1#118bis meeting in cyan:
Agreement
For PUSCH intra-slot frequency hopping in SBFD symbols, the starting RB in each hop is given by:
For PUSCH inter-slot frequency hopping in SBFD symbols
and when pusch-DMRS-Bundling is not enabled, or for
inter-slot frequency hopping for a PUSCH in SBFD symbols scheduled by RAR UL
grant or DCI format 0_0 with CRC scrambled by TC-RNTI, the starting RB during
slot 
is given by:
Where
·
is the starting PRB
index of UL usable PRBs with reference to the start of UL active BWP.
·
is the number of UL
usable PRBs.
·
is the starting PRB
index of the first PUSCH hop with reference to the start of UL active BWP. For PUSCH transmissions with Configuration 2, 
is the
starting PRB index
with
reference to the start of UL active BWP after applying RB offset between
non-SBFD symbols and SBFD symbols.
· RB offset is the frequency hopping offset for PUSCH in SBFD symbols
·
Note:
Definition of 
is unchanged from
existing specifications
Decide in RAN1#119,
one of the following options:
·
Alt1: Remove 
in the
above equations
·
Alt2: Remove square brackets from 
in the
above equations
Agreement
For dynamically scheduled PDSCH repetitions with Configuration 2, for TBS determination.
Agreement
Red text is working assumption.
For separate SRS configurations for SBFD and non-SBFD symbols, support Option 1.
Option 1: Support separate SRS-ResourceSets configurations for SBFD and non-SBFD symbols for a given usage.
o For periodic and semi-persistent SRS, the SRS transmissions in non-SBFD symbols are dropped.
o For aperiodic SRS with available slot counting, only SBFD symbols are available for SRS transmission.
§ FFS impact on availableSlotOffsetList
o For aperiodic SRS without available slot counting, it is expected that UE is indicated to transmit SRS in the SBFD symbols.
o FFS: whether there is impact on frequency hopping counter
· SRS-ResourceSet configured for non-SBFD symbol is only applicable to SRS transmission occasions in non-SBFD symbols.
o For periodic and semi-persistent SRS, the SRS transmissions in SBFD symbols are dropped.
o For aperiodic SRS with available slot counting, only non-SBFD symbols are available for SRS transmission.
§ FFS impact on availableSlotOffsetList
o For aperiodic SRS without available slot counting, it is expected that UE is indicated to transmit SRS in the non-SBFD symbols.
o FFS: whether there is impact on frequency hopping counter
· The number of SRS resources in a SRS-ResourceSet for SBFD symbols is the same as the number of SRS resources in a SRS-ResourceSet for non-SBFD symbols for the same usage.
· For SRS-ResourceSets with usage set to 'nonCodebook', only one SRS port for each SRS resource is configured as legacy.
· For SRS-ResourceSets with usage set to 'Codebook',
o Except when higher layer parameter ul-FullPowerTransmission is set to 'fullpowerMode2', the numbers of SRS ports are the same for all the SRS resources in the two SRS-ResourceSets
o FFS when higher layer parameter ul-FullPowerTransmission is set to 'fullpowerMode2'
· Maintain single TRP behaviour with respect to DCI fields and RRC parameters in rrc-ConfiguredUplinkGrant
o SRS resource set indicator (SRSI) field is absent from DCI. srs-ResourceSetId is absent in rrc-ConfiguredUplinkGrant.
o If txConfig is set to 'codebook', second precoding information (TPMI) field is absent from DCI and precodingAndNumberOfLayers2 is absent from rrc-ConfiguredUplinkGrant.
o Second SRS resource indicator (SRI) field is absent from DCI
§ For DG PUSCH without repetition within a slot, the indicated SRI in slot n is associated with the most recent transmission of SRS resource identified by the SRI in the same symbol type as that of PUSCH transmission, where the SRS resource prior to the PDCCH carrying the SRI.
· If txConfig is set to 'codebook', the precoding information and number of layers (TPMI) field in DCI corresponds to the SRS resource identified by the SRI in the SRS-ResourceSet corresponding to the same symbol type as that of PUSCH transmission
§ For DG PUSCH with repetition/multi-PUSCH scheduled by a single DCI/TBoMS/Type 2 CG PUSCH with Configuration 1, the indicated SRI in slot n is associated with the most recent transmission of SRS resource identified by the SRI in the same symbol type as the valid symbol type of PUSCH transmission, where the SRS resource prior to the PDCCH carrying the SRI.
· If txConfig is set to 'codebook', the precoding information and number of layers (TPMI) field in DCI corresponds to the SRS resource identified by the SRI in the SRS-ResourceSet corresponding to the same symbol type as the valid symbol type of PUSCH transmission
§ For DG PUSCH with repetition/multi-PUSCH scheduled by a single DCI/TBoMS/Type 2 CG PUSCH with Configuration 2, the SRS resource indicator is applicable to both SBFD and non-SBFD SRS-ResourceSets. For PUSCH transmissions in SBFD symbols, the indicated SRI in slot n is associated with the most recent transmission of SRS resource identified by the SRI in SBFD symbols, where the SRS resource is prior to the PDCCH carrying the SRI. For PUSCH transmissions in non-SBFD symbols, the indicated SRI in slot n is associated with the most recent transmission of SRS resource identified by the SRI in non-SBFD symbols, where the SRS resource is prior to the PDCCH carrying the SRI.
· If txConfig is set to 'codebook', for PUSCH transmission in SBFD symbols, the precoding information and number of layers (TPMI) field in DCI corresponds to the SRS resource identified by the SRI in the SRS-ResourceSet corresponding to SBFD symbols. For PUSCH transmission in non-SBFD symbols, the precoding information and number of layers (TPMI) field in DCI corresponds to the SRS resource identified by the SRI in the SRS-ResourceSet corresponding to non-SBFD symbols.
§ If only a single SRS resource is configured in both SRS resource sets, the SRI field is absent from DCI. In this case “SRS resource identified by the SRI” in the above bullets corresponds to the single SRS resource in each SRS resource set.
o srs-ResourceIndicator2 is absent from rrc-ConfiguredUplinkGrant.
§ For Type 1 CG PUSCH with Configuration 1, srs-ResourceIndicator is associated with the most recent transmission of SRS resource identified by the SRI in the same symbol type as the valid symbol type of PUSCH transmission.
· If txConfig is set to 'codebook', precodingAndNumberOfLayers corresponds to the SRS resource identified by the SRI in the SRS-ResourceSet corresponding to the same symbol type as the valid symbol type of PUSCH transmission.
§ For Type 1 CG PUSCH with Configuration 2, srs-ResourceIndicator is applicable to both SBFD and non-SBFD SRS-ResourceSets. For PUSCH transmissions in SBFD symbols, the srs-ResourceIndicator is associated with the most recent transmission of SRS resource identified by the SRI in SBFD symbols. For PUSCH transmissions in non-SBFD symbols, the srs-ResourceIndicator is associated with the most recent transmission of SRS resource identified by the SRI in non-SBFD symbols.
· If txConfig is set to 'codebook', for PUSCH transmission in SBFD symbols, precodingAndNumberOfLayers corresponds to the SRS resource identified by the SRI in the SRS-ResourceSet corresponding to SBFD symbols. For PUSCH transmission in non-SBFD symbols, precodingAndNumberOfLayers corresponds to the SRS resource identified by the SRI in the SRS-ResourceSet corresponding to non-SBFD symbols.
o If txConfig is set to 'nonCodebook', each SRS resource set is associated with an associated CSI-RS.
· Applicable to usage set to 'codebook' or 'nonCodebook'
· FFS usage set to 'beamManagement'
· Not applicable to usage set to 'antennaSwitching’
Conclusion
There is no RAN1 consensus to support mTRP scenario for SBFD in Rel-19.
Agreement
The maximum number of power control loops is the same as legacy (i.e. no more than 2) for SBFD operation in Rel-19.
Agreement
For a serving cell configured with SBFD subband time and frequency location, for an SBFD aware UE, SFI in DCI format 2_0 is only applicable to non-SBFD symbols but not applicable to SBFD symbols
· Note: no additional specification efforts are expected to support joint operation of SBFD and dynamic SFI.
R1-2410694 Summary #3 of SBFD TX/RX/measurement procedures Moderator (CATT)
From Thursday session
Agreement:
For Configuration 1: The transmissions/receptions are restricted to SBFD symbols only or non-SBFD symbols only,
· For type 2 CG PUSCH, SPS PDSCH, down-select from the following options:
o The valid symbol type for type 2 CG PUSCH is determined based on the symbol type of the first CG PUSCH associated with activation DCI.
o The valid symbol type for SPS PDSCH is determined based on the symbol type of the first SPS PDSCH associated with activation DCI.
Agreement
At least in case when PUSCH frequency hopping is not enabled, for a CG PUSCH configuration without repetitions, if the transmission occasions are across SBFD symbols and non-SBFD symbols where each transmission occasion has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), for PUSCH repetition type-A across SBFD symbols and non-SBFD symbols in different slots where each repetition has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), and for multi-PUSCH scheduled by a single DCI across SBFD symbols and non-SBFD symbols, where each PUSCH within a slot has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), and for TBoMS across SBFD symbols and non-SBFD symbols in different slots, where each transmission within a slot has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), for determining starting PRB for PUSCH transmissions in SBFD symbols,
is not
configured, it is zero
Agreement
For a single TRP scenario, for separate UL power control for PUSCH/PUCCH/SRS transmissions in SBFD symbols and non-SBFD symbols based on unified TCI state framework,
Agreement
For UL transmissions and DL receptions across SBFD symbols and non-SBFD symbols in different slots (each transmission/reception within a slot has either all SBFD or all non-SBFD symbols) for an SBFD aware UE,
Agreement
It is clarified that ‘the first transmission/reception’ in the following agreement in RAN1#118 refers to the first transmission/reception occasion indicated by scheduling DCI.
· It is not expected that the first transmission/reception occasion indicated by scheduling DCI is mapped to both SBFD and non-SBFD symbols.
Agreement
For Configuration 1: The transmissions/receptions are restricted to SBFD symbols only or non-SBFD symbols only, the valid symbol type is determined as following.
<Unrelated part omitted>
· For dynamically scheduled transmissions/receptions, the valid symbol type is determined based on the symbol type of the first transmission/reception.
<Unrelated part omitted>
R1-2409375 Discussion for SBFD random access operation New H3C Technologies Co., Ltd.
R1-2409411 On subband full duplex random access operation Huawei, HiSilicon
R1-2409453 Discussion on SBFD Random Access Operation MediaTek Inc.
R1-2409475 Discussion on SBFD random access operation TCL
R1-2409489 Discussion on SBFD random access operation LG Electronics
R1-2409509 Discussion on SBFD random access operation CMCC
R1-2409539 Discussion on SBFD random access operation ZTE Corporation, Sanechips
R1-2409567 On SBFD random access operation InterDigital, Inc.
R1-2409594 Random access on SBFD resources Samsung
R1-2409633 Discussion on SBFD random access operation Spreadtrum, UNISOC
R1-2409678 Discussion on random access for Rel-19 SBFD vivo
R1-2409764 Discussion on SBFD Random Access Operation Tejas Networks Limited
R1-2409797 Views on SBFD random access operation Apple
R1-2409844 Discussion on SBFD random access operation Ruijie Networks Co. Ltd
R1-2409873 Discussion on random access for SBFD NEC
R1-2409893 Discussion on SBFD random access operation Xiaomi
R1-2409910 Discussion on SBFD random access operation Korea Testing Laboratory
R1-2409938 Discussion on SBFD random access operation CATT
R1-2409964 Discussion on SBFD random access operation Transsion Holdings
R1-2409999 Discussion on SBFD random access operation China Telecom
R1-2410046 Discussion on SBFD random access operation Panasonic
R1-2410058 Discussion on SBFD random access operation Fujitsu
R1-2410087 Discussion on SBFD random access operation OPPO
R1-2410138 SBFD random access operation Nokia, Nokia Shanghai Bell
R1-2410141 SBFD Random access operation Ericsson
R1-2410172 Discussion on SBFD random access operation Hyundai Motor Company
R1-2410223 SBFD RACH Operations Sony
R1-2410251 SBFD random access operation Lenovo
R1-2410265 SBFD random access operation ETRI
R1-2410324 On SBFD random access operation Google Ireland Limited
R1-2410345 Discussion on SBFD Random Access operation KT Corp.
R1-2410386 Discussion on SBFD random access operation NTT DOCOMO, INC.
R1-2410412 SBFD random access aspects Sharp
R1-2410429 Discussion on SBFD random access operation for SBFD aware UEs ITRI
R1-2410475 SBFD Random Access Operation Qualcomm Incorporated
R1-2410544 Discussion on SBFD random access operation ASUSTEK COMPUTER (SHANGHAI)
R1-2410559 Discussion on SBFD random access operation WILUS Inc.
R1-2410575 Discussion on SBFD random access operation CEWiT
R1-2410674 Summary#1 on SBFD random access operation Moderator (CMCC)
From Tuesday session
Agreement
Introduce explicit indications (1-bit SIB1 indication and/or dedicated signalling to convey cell-specific configuration) to indicate whether RACH configuration Option 1 for SBFD random access operation is enabled or not from network side.
Agreement
For RACH configuration Option 1, for support of separate power control parameters for PRACH transmission in additional-ROs and legacy-ROs, support separate preambleReceivedTargetPower for additional-ROs.
,
preambleTransMax, powerRampingStepHighPriority
Agreement
For RACH configuration Option 2, the association period and association pattern period of additional-ROs are determined separately from legacy-ROs.
Agreement
Confirm the following working assumption
Working Assumption
For a PRACH transmission with 
preamble
repetition within additional-ROs, support reusing current specification rules
for the determination of the set of valid
additional-ROs and the time period of the set(s) of valid
additional-ROs.
·
The time period
of the set(s) of valid
additional-ROs is determined separately from the time period for legacy-ROs.
Agreement
It is up to RAN2 to determine the detailed specified/configured conditions/prioritizations for RO selection for initial PRACH transmission attempt in one random access procedure.
Agreement
For CFRA triggered by PDCCH order for SBFD aware-UEs, SBFD-aware UE is explicitly indicated to use additional-RO or legacy-RO via a 1-bit field in the DCI of PDCCH order.
R1-2410675 Summary#2 on SBFD random access operation Moderator (CMCC)
From Wednesday session
Agreement
For RACH configuration Option 2, and for interpretation of the parameter prach-ConfigurationIndex provided by the additional RACH configuration, down-select from the following options:
Agreement
For RACH configuration Option 2, support separate configuration of rsrp-ThresholdMsg1-RepetitionNum2/4/8 and msg1-RepetitionNum for PRACH transmission with preamble repetitions within additional-ROs and PRACH transmission with preamble repetitions within legacy-ROs.
· msg1-RepetitionNum is configured in RACH-ConfigCommon in current specification, i.e., for RACH configuration Option 2, msg1-RepetitionNum can already be separately configured for legacy-ROs and additional-ROs.
Agreement
For RACH configuration Option 1, support separate configuration of rsrp-ThresholdMsg1-RepetitionNum2/4/8 for PRACH transmission with preamble repetitions within additional-ROs and PRACH transmission with preamble repetitions within legacy-ROs.
· Same msg1-RepetitionNum is used for PRACH transmission with preamble repetitions within additional-ROs and PRACH transmission with preamble repetitions within legacy-ROs.
Agreement
For SBFD aware UEs, for Msg3 PUSCH transmission,
·
the number of 
hopping bits is based on the number of PRBs in initial UL BWP as in
legacy specification.
·
the frequency offset for
the 2nd hop is reserved for the case when the value of = 11 as in legacy specification.
Agreement
For an SBFD aware UE, if addition RO is selected for Msg1 transmission, only Configuration 1 is supported for Msg3 repetition.
Agreement
For determining PUCCH resource sets in SBFD symbols before dedicated PUCCH resource configuration, reuse the Table 9.2.1-1 in TS 38.213, with the following modifications:
· use the size of UL usable PRBs to replace the size of initial UL BWP to determine the PRB offset in row index 15.
Agreement
For RACH configuration Option 1 with Alt 1-1, for determination of lowest RO of additional-ROs in SBFD symbols, Alt 2-1 is supported.
· Alt 2-1: The parameter msg1-FrequencyStart in rach-ConfigCommon is reinterpreted as the frequency offset of lowest RO in frequency domain with respective to the lowest PRB of UL usable PRBs.
· ROs that are outside of UL usable PRBs are invalid.
Agreement
For SBFD aware UEs, update the following equations to determine the lowest PRB indices of the PUCCH transmission in the first hop and second hop in SBFD symbols before dedicated PUCCH resource configuration:
for
the first hop
for
the second hop
for
the first hop
for
the second hopWhere
is
the starting PRB index of UL usable PRBs with reference to the start of UL
active BWP. is
the number of UL usable PRBs.
is
the RB offset with reference Note:
Definitions of 
, 
and 
are unchanged from
existing specifications.
R1-2410676 Summary#3 on SBFD random access operation Moderator (CMCC)
From Thursday session
Agreement
For RACH configuration Option 2, for the case that additional ROs overlap with legacy ROs, down-select from the following alternatives:
· Alt-1: do not optimize this case.
· Alt-2: the additional-ROs are considered invalid when overlapping with legacy-ROs.
Agreement
For Msg3 PUSCH repetition Configuration 1, the valid symbol type is determined based on the symbol type of the first transmission occasion.
· UE does not expect the first transmission occasion includes different symbol types (i.e., SBFD symbols and non-SBFD symbols).
· FFS: Available slot counting on SBFD symbols.
Agreement
Study how to determine the Msg3 PUSCH power control in SBFD symbols and non-SBFD symbols based on at least the following parameters.
in
RAR.R1-2409376 Discussion on CLI handling New H3C Technologies Co., Ltd.
R1-2409412 On cross-link interference handling for subband full duplex Huawei, HiSilicon
R1-2409454 Discussion on CLI Handling in SBFD System MediaTek Inc.
R1-2409490 Discussion on CLI handling LG Electronics
R1-2409510 Discussion on CLI handling CMCC
R1-2409540 Discussion on CLI handling for Rel-19 duplex operation ZTE Corporation, Sanechips
R1-2409568 On CLI handling for SBFD operation InterDigital, Inc.
R1-2409595 Cross-link interference handling for SBFD Samsung
R1-2409634 Discussion on CLI handling Spreadtrum, UNISOC
R1-2409679 Discussion on CLI handling for Rel-19 NR duplex vivo
R1-2409765 Discussion on gNB-gNB CLI handling Tejas Networks Limited
R1-2409798 Discussion on CLI handling Apple
R1-2409874 CLI handling for NR duplex operations NEC
R1-2409894 Discussion on CLI handling for SBFD operation Xiaomi
R1-2409939 Discussion on CLI handling for NR duplex evolution CATT
R1-2410047 Discussion on CLI handling Panasonic
R1-2410088 CLI handling in NR duplex operation OPPO
R1-2410139 Cross-link interference handling for duplex evolution Nokia, Nokia Shanghai Bell
R1-2410142 CLI handling Ericsson
R1-2410224 SBFD CLI Handling Sony
R1-2410266 Discussion on CLI handling for SBFD operation ETRI
R1-2410325 On the gNB-to-gNB CLI and the UE-to-UE CLI handling Google Ireland Limited
R1-2410387 Discussion on CLI handling NTT DOCOMO, INC.
R1-2410433 Views on uplink resource muting SHARP Corporation
R1-2410476 Enhancements for CLI handling Qualcomm Incorporated
R1-2410576 Discussion on CLI handling CEWiT
R1-2410788 Summary #1 of CLI handling Moderator (Huawei)
From Tuesday session
Agreement
Define a new IE SRS-RSRP-MeasurementResourceSet containing a set of SRS-RSRP measurement resource(s) SRS-RSRP-MeasurementResource for L1 SRS-RSRP measurement
· Configuration of slot offset between the slot containing the DCI that triggers a set of aperiodic SRS-RSRP resources and the slot in which the SRS-RSRP resource set is measured (already agreed in RAN1#118bis)
· FFS: Other configurations
Define SRS-RSRP-MeasurementResource with the following parameters:
· Legacy SRS Resource IE
· FFS: Other parameters
Agreement
Define a new IE CLI-RSSI-MeasurementResourceSet containing a set of CLI-RSSI measurement resource CLI-RSSI-MeasurementResource for L1 CLI-RSSI measurement.
· Configuration of the slot offset between the slot containing the DCI that triggers a set of aperiodic CLI-RSSI resources and the slot in which the CLI-RSSI resource set is measured (already agreed in RAN1#118bis)
Define CLI-RSSI-MeasurementResource with the following parameters:
· CLI-RSSI measurement resource ID
· Starting PRB index
· Number of PRBs
· Starting symbol of the CLI-RSSI resource within a slot
· Number of symbols of the CLI-RSSI resource within a slot
· Periodicity and slot offset for the CLI-RSSI resource
· FFS: Other parameters
Agreement
To determine the time location of UL muting symbol(s) in a slot for a PUSCH, the following option is selected for DG PUSCH and Type 2 CG PUSCH
· Option 2: The time location of each of one or two UL muting symbols is semi-statically configured, and muting all of the semi-statically configured time location of UL muting symbol(s) can be dynamically turned ON/OFF by TDRA field in DCI.
R1-2410789 Summary #2 of CLI handling Moderator (Huawei)
From Wednesday session
Agreement
For the frequency location configuration of UL resource muting for a PUSCH, at least for CP-OFDM
· A comb offset {0, 1} is configured for the up to two UL muting symbols.
Working assumption
For the frequency location configuration of UL resource muting for a PUSCH, for DFT-S-OFDM
· A comb offset {0, 1} is configured for the up to two UL muting symbols.
Agreement
If an UL resource muting symbol overlaps with a symbol containing UL DMRS for a PUSCH, DMRS is prioritized, i.e., UE does not apply UL resource muting in the symbol.
Agreement
If an UL muting symbol overlaps with a symbol containing PT-RS for a PUSCH and transform precoding is not enabled for the PUSCH, the UE does not expect the muted REs overlaps the REs occupied by PT-RS.
Agreement
Confirm the following working assumption
Working Assumption
UL resource muting is allowed on PUSCH symbols that carry UCI, i.e., UCI is not mapped on muted REs
Note: As mentioned in the WID, no specification changes are allowed on data and control multiplexing in section 6.2.7, TS 38.212.
Agreement
For aperiodic L1 CLI-RSSI/CLI-SRS-RSRP reporting on PUSCH based on a set of periodic CLI measurement resources, the TCI state(s) with QCL typeD for the CLI measurement resources in the periodic CLI measurement resource set are configured per CLI measurement resource (either for all resources in the set or none) by higher-layer parameter
· For each periodic CLI measurement resource, this higher-layer parameter provides a reference to one TCI-State in TCI-States for providing the QCL source and QCL typeD.
· If the TCI state is not configured, the UE QCL assumptions are the default rules agreed in RAN1#118bis
For aperiodic L1 CLI-RSSI/CLI-SRS-RSRP reporting on PUSCH based on a set of semi-persistent CLI measurement resources, the gNB may activate and deactivate the configured semi-persistent CLI measurement resource sets by sending a new SP CLI Measurement Resource Set Activation/Deactivation MAC CE
· TCI state IDi field is included in the new MAC CE, which is used as typeD QCL source for the CLI measurement resource within the Semi Persistent CLI measurement resource set. Either all TCI state ID fields are present or none.
· If the TCI state ID field(s) are absent, the UE QCL assumptions are the default rules agreed in RAN1#118bis
Agreement
For L1 UE-to-UE CLI measurement and reporting, Method#3 is supported
· Method #3: UE measures RSSI within UL subband
· A UE cannot be configured to perform measurement using Method #1 and Methods#3 in the same OFDM symbol. Measurement resource(s) corresponding to Methods #1 and #3 shall not be associated with the same CSI-ReportConfig.
Conclusion
There is no RAN1 consensus on the following:
· Subband CLI-RSSI reporting for L1 CLI-RSSI measurement in Rel-19.
R1-2410790 Summary #3 of CLI handling Moderator (Huawei)
From Thursday session
Agreement
3dB power boosting is assumed for REs in the PUSCH symbol not containing PT-RS with UL resource muting.
· FFS: PUSCH and PT-RS EPRE determination for the PUSCH symbol containing PT-RS with UL resource muting when transform precoding is not enabled.
Include the above in the LS to RAN4. In addition, mention that RAN1 is still discussing the boosting in symbols containing PTRS.
Agreement
Send an LS to RAN4 with the following contents:
On UL resource muting, RAN1 has made the following agreements
|
Agreement If UL resource muting is applied on a symbol for a PUSCH, a comb-2 pattern is applied for all of the allocated PRBs of the PUSCH on that symbol.
Agreement To determine the time location of UL muting symbol(s) in a slot for a PUSCH, the following option is selected for DG PUSCH and Type 2 CG PUSCH - Option 2: The time location of each of one or two UL muting symbols is semi-statically configured, and muting all of the semi-statically configured time location of UL muting symbol(s) can be dynamically turned ON/OFF by TDRA field in DCI
Agreement For the frequency location configuration of UL resource muting for a PUSCH, at least for CP-OFDM - A comb offset {0, 1} is configured for the up to two UL muting symbols
Working assumption For the frequency location configuration of UL resource muting for a PUSCH, for DFT-S-OFDM - A comb offset {0, 1} is configured for the up to two UL muting symbols
Agreement If an UL resource muting symbol overlaps with a symbol containing UL DMRS for a PUSCH, DMRS is prioritized, i.e., UE does not apply UL resource muting in the symbol.
Agreement If an UL muting symbol overlaps with a symbol containing PT-RS for a PUSCH and transform precoding is not enabled for the PUSCH, the UE does not expect the muted REs overlaps the REs occupied by PT-RS.
Agreement 3dB power boosting is assumed for REs in the PUSCH symbol not containing PT-RS with UL resource muting. · FFS: PUSCH and PT-RS EPRE determination for the PUSCH symbol containing PT-RS with UL resource muting when transform precoding is not enabled. |
Note that RAN1 is still discussing the boosting in symbols containing PTRS. RAN1 would like to ask RAN4 to check impact on transmit signal quality/MPR, if any.
Final LS is in R1-2410889.
Agreement
Send reply LS to RAN4 with following information:
When discussing L1 UE-to-UE CLI measurement reporting, RAN1 has not made a distinction between the two application scenarios mentioned in the RAN4 LS (intra-cell vs. inter-cell UE-to-UE L1 CLI measurement). L1 UE-to-UE CLI measurement and reporting specified by RAN1 can be applied for both application scenarios.
For the case of intra-cell L1 SRS-RSRP measurement and reporting, a victim UE may be configured with a set of SRS-RSRP measurement resources that overlap with the resources used by the aggressor UE(s) to transmit SRS since the gNB has knowledge the aggressor UE’s SRS configurations.
However, for inter-cell L1 SRS-RSRP measurement, SRS resource set configurations may need to be exchanged among gNBs. But specification impact of this in Xn/F1 has been excluded according the following note from the WID
• The measurement resources for SRS-RSRP are based on the existing legacy RS patterns. No specification impact for SRS configuration information exchange between gNBs
From RAN1 perspective, intra-cell UE-to-UE L1 CLI measurement scenario can be prioritized for the requirements of L1 SRS-RSRP measurement.
Final LS is in R1-2410890.
Conclusion
For Method#1 (RSSI measurement within DL subband) with the frequency resources of CLI-RSSI measurement resource type#2 (One CLI-RSSI measurement resource across two DL subbands), two per-DL-subband CLI-RSSI measurements reports with wideband report in each DL-subband is not supported.
Conclusion
There is no RAN1 consensus to support aperiodic CLI reporting on PUCCH in Rel-19.
Agreement
For a CSI report with CSI-ReportConfig with higher layer parameter reportQuantity set to ‘cli-RSSI’ or ‘cli-SRS-RSRP’, the following are supported
· The number of reported CLI measurement resources M can be configured as {1, 2, 3, 4}
· The M CLI measurement resource ID(s) are reported
· The absolute (not differential) value of the most interfered (largest) measured L1-CLI-RSSI or L1-SRS-RSRP is reported
· When the number of reported CLI measurement resources is larger than one, a differential reporting method is used taking the most interfered measured L1-CLI-RSSI or L1-SRS-RSRP as the reference
· FFS: other reporting criteria, e.g., the least interfered measured L1-CLI-RSSI or L1-SRS-RSRP
· FFS: whether/how to report differential value in case the largest measurement is out of range
Agreement
For PUSCH repetition Type A in SBFD symbols with Configuration 1, the same time location of none, one or two UL muting symbol(s) is applied for all PUSCH repetitions.
For PUSCH repetition Type B in SBFD symbols with Configuration 1, the same time location of none, one or two UL muting symbol(s) per slot is applied for all the actual PUSCH repetitions.
Agreement
If transform precoding is enabled for a PUSCH, study further the following two options:
·
Option 1: The DFT size is
modified as 
for symbol(s) with UL resource muting
·
Option 2: The DFT size is 
for symbol(s) with UL resource muting
Note:
is the total number of
subcarriers of the PUSCH.
FFS: Whether any of option 1, option 2 needs to be reflect into RAN1 specifications.
Please refer to RP-241614 for detailed scope of the WI.
Rapporteur to provide initial input on higher layer signalling under agenda item 9.3. For input on higher layer signalling from any other source, please include it as part of your tdoc to relevant sub-agenda items.
[120-R19-Duplex] – Xinghua (Huawei)
Email discussion on Rel-19 SBFD
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2500157 Higher layer parameters for Rel-19 SBFD Huawei, HiSilicon
From AI5
R1-2500019 LS on CSI-RS measurement with SBFD operation RAN4, MediaTek
Decision: RAN4 is requesting clarification from RAN1 on CSI-RS measurement with SBFD operation to progress with their RRM requirement. RAN1 response is necessary - Mohamed (MediaTek)
R1-2501536 Summary of Discussion on LS on CSI-RS measurement with SBFD operation Moderator (MediaTek)
From Wednesday session
R1-2501537 Draft Reply LS on CSI-RS measurement with SBFD operation Moderator (MediaTek)
Decision: Response to RAN4 in R1-2501537 is endorsed. Final LS is approved in R1-2501560.
Including semi-static indication of SBFD resources.
R1-2500061 Discussion on SBFD TX/RX/measurement procedures TCL
R1-2500093 On subband full duplex design Huawei, HiSilicon
R1-2500144 Discussion on transmission, reception and measurement procedures for SBFD operation ZTE Corporation, Sanechips
R1-2500166 Discussion on SBFD TX/RX/measurement procedures Spreadtrum, UNISOC
R1-2500221 Discussion on SBFD TX/RX/measurement procedures CATT
R1-2500249 Discussion on SBFD TX/RX/measurement procedures LG Electronics
R1-2500257 Discussion on SBFD TX/RX/measurement procedures China Telecom
R1-2500283 Discussion on SBFD TX/RX/measurement procedures CMCC
R1-2500314 Discussion on SBFD TX/RX/measurement procedures MediaTek Inc.
R1-2500346 Discussion on Rel-19 SBFD operation vivo
R1-2500401 Discussion for SBFD TX/RX/ measurement procedures Tejas Networks Limited
R1-2500454 Discussion on SBFD Tx/Rx/measurement procedures OPPO
R1-2500500 Discussion on SBFD Tx/Rx/measurement procedures Fraunhofer HHI, Fraunhofer IIS
R1-2500515 Discussion on SBFD TX/RX/measurement procedures Ofinno
R1-2500520 Views on SBFD TX_RX_measurement procedures InterDigital, Inc.
R1-2500620 Discussion on subband non-overlapping full duplex Tx-Rx and measurement operations NEC
R1-2500648 SBFD procedures Sony
R1-2500697 Discussion on SBFD TX/RX/measurement procedures Panasonic
R1-2500729 Discussion on reception and transmission procedure for SBFD operation Xiaomi
R1-2500749 SBFD TX/RX/measurement procedures Ericsson
R1-2500775 Discussion on SBFD TX/RX/measurement procedures Apple
R1-2500847 SBFD operation and procedures Samsung
R1-2500880 Discussion on SBFD TX/RX/ measurement procedures CEWiT
R1-2500908 Discussion on SBFD TX/RX/measurement procedures ETRI
R1-2500934 Discussion on SBFD Tx/Rx/measurement procedures Fujitsu
R1-2500965 Discussion on SBFD operation Transsion Holdings
R1-2500988 Discussion on SBFD TX/RX/measurement procedures Kookmin University
R1-2501003 On SBFD TX/RX/measurement procedures Nokia, Nokia Shanghai Bell
R1-2501010 Views on SBFD TX/RX Measurement Procedures Lenovo
R1-2501052 SBFD Tx/Rx/measurement procedures Charter Communications, Inc
R1-2501055 SBFD Tx/Rx/measurement aspects Sharp
R1-2501088 Discussion on SBFD TX/RX/measurement procedures Hyundai Motor Company
R1-2501107 Discussion on SBFD TX/RX/measurement procedures HONOR
R1-2501153 SBFD Transmission, Reception and Measurement Procedures Qualcomm Incorporated
R1-2501199 Discussion on SBFD TX/RX/measurement procedures NTT DOCOMO, INC.
R1-2501228 Discussion on SBFD TX/RX/measurement procedures Google Korea LLC
R1-2501231 Discussion on SBFD TX/RX/measurement procedures ITRI
R1-2501240 Partial PRG handling for SBFD ASUSTeK
R1-2501285 Discussion on SBFD TX/RX/measurement procedures WILUS Inc.
R1-2501338 Summary #1 of SBFD TX/RX/measurement procedures Moderator (Xiaomi)
From Tuesday session
Agreement
For aperiodic SRS with available slot counting,
· For SRS-ResourceSet configured for SBFD symbol, an available slot is a slot satisfying there are SBFD symbol(s) for the time-domain location(s) for all the SRS resources in the resource set and it satisfies UE capability on the minimum timing requirement between triggering PDCCH and all the SRS resources in the resource set.
· For SRS-ResourceSet configured for non-SBFD symbol, an available slot is a slot satisfying there are UL or flexible symbol(s) not configured as SBFD symbols for the time-domain location(s) for all the SRS resources in the resource set and it satisfies UE capability on the minimum timing requirement between triggering PDCCH and all the SRS resources in the resource set.
Agreement
The configuration of Configuration 1 or 2 for DL BWP only applies to PDSCH receptions within the DL BWP.
Agreement
For a CSI report associated with periodic/semi-persistent CSI-RS, the valid symbol type for CSI derivation is configured in CSI-ReportConfig.
Agreement
For Configuration 1: The transmissions/receptions are restricted to SBFD symbols only or non-SBFD symbols only,
Conclusion
Agreement
For determining starting PRB for PUSCH transmissions in SBFD symbols for Configuration 2,
is configured in rrc-ConfiguredUplinkGrant
in ConfiguredGrantConfig. is configured per UL BWP in PUSCH-Config.
is commonly applicable to all DCI formats which schedule PUSCH
is not configured, it is assumed to be zero
Agreement
When higher layer parameter ul-FullPowerTransmission is set to 'fullpowerMode2', the numbers of SRS ports should be the same for SRS resources with the same corresponding SRI values in the two SRS resource sets associated with SBFD and non-SBFD symbols.
R1-2501339 Summary #2 of SBFD TX/RX/measurement procedures Moderator (Xiaomi)
From Wednesday session
Agreement
For Configuration 1: The transmissions/receptions are restricted to SBFD symbols only or non-SBFD symbols only,
· The valid symbol type for Type 1 CG PUSCH is configured in rrc-ConfiguredUplinkGrant in ConfiguredGrantConfig.
· The valid symbol type for PUCCH configured for SR is configured in SchedulingRequestResourceConfig.
· The valid symbol type for PUCCH carrying P-CSI is configured in periodic in CSI-ReportConfig.
Agreement
For a type 1 CG PUSCH with Configuration 2, if FH offset for SBFD symbols is not configured for the type 1 CG PUSCH, frequency hopping is disabled for the type 1 CG PUSCH transmissions in SBFD symbols.
For a type 2 CG PUSCH/PUSCH scheduled by DCI, if FH offset lists for SBFD symbols are not configured for the type 2 CG PUSCH/PUSCH scheduled by DCI, frequency hopping is disabled for the transmission of the type 2 CG PUSCH/PUSCH scheduled by DCI in SBFD symbols.
Agreement:
For SPS PDSCH with Configuration 2, for TBS determination,
R1-2501340 Summary #3 of SBFD TX/RX/measurement procedures Moderator (Xiaomi)
From Thursday session
Agreement
If starting PRB is not configured for SBFD symbols for a PUCCH-Resource, starting PRB configured for non-SBFD symbols for the PUCCH-Resource is used for PUCCH transmissions in SBFD symbols associated with this pucch-ResourceId.
Agreement
The one configuration of intraSlotFrequencyHopping for a PUCCH-Resource is applied to both PUCCH transmissions in SBFD symbols and in non-SBFD symbols associated with this pucch-ResourceId.
Agreement
Support SBFD operation on one TDD carrier in multi-carrier scenario.
· Note: If the TDD carrier for SBFD operation is an Scell, support UE dedicated signaling for cell-specific configuration of time and frequency location of SBFD subbands for the Scell.
· FFS whether/how to handle half-duplex CA case
R1-2500062 Discussion on SBFD random access operation TCL
R1-2500094 On subband full duplex random access operation Huawei, HiSilicon
R1-2500145 Discussion on SBFD random access operation ZTE Corporation, Sanechips
R1-2500167 Discussion on SBFD random access operation Spreadtrum, UNISOC
R1-2500222 Discussion on SBFD random access operation CATT
R1-2500250 Discussion on SBFD random access operation LG Electronics
R1-2500258 Discussion on SBFD random access operation China Telecom
R1-2500284 Discussion on SBFD random access operation CMCC
R1-2500315 Discussion on SBFD Random Access Operation MediaTek Inc.
R1-2500347 Discussion on random access for Rel-19 SBFD vivo
R1-2500402 Discussion on SBFD Random Access Operation Tejas Networks Limited
R1-2500455 Discussion on SBFD random access operation OPPO
R1-2500516 Discussion on SBFD for random-access procedure Ofinno
R1-2500521 Discussion on SBFD random access operation InterDigital, Inc.
R1-2500587 Discussion on random access for SBFD NEC
R1-2500649 SBFD RACH operations Sony
R1-2500698 Discussion on SBFD random access operation Panasonic
R1-2500730 Discussion on SBFD random access operation Xiaomi
R1-2500750 SBFD Random access operation Ericsson
R1-2500776 Views on SBFD random access operation Apple
R1-2500848 Random access on SBFD resources Samsung
R1-2500881 Discussion on SBFD random access operation CEWiT
R1-2500883 SBFD random access operation Lenovo
R1-2500909 SBFD random access operation ETRI
R1-2500935 Discussion on SBFD random access operation Fujitsu
R1-2500966 Discussion on SBFD random access operation Transsion Holdings
R1-2500989 Discussion on SBFD random access operation Kookmin University
R1-2501004 SBFD random access operation Nokia, Nokia Shanghai Bell
R1-2501056 SBFD random access aspects Sharp
R1-2501154 SBFD Random Access Operation Qualcomm Incorporated
R1-2501200 Discussion on SBFD random access operation NTT DOCOMO, INC.
R1-2501227 Discussion on SBFD Random Access operation KT Corp.
R1-2501232 Discussion on SBFD random access operation for SBFD aware UEs ITRI
R1-2501286 Discussion on SBFD random access operation WILUS Inc.
R1-2501291 On SBFD random access operation Google Ireland Limited
R1-2501415 Summary#1 on SBFD random access operation Moderator (CMCC)
From Tuesday session
Conclusion
There is no RAN1 consensus on the following proposal:
For RACH configuration Option 1, for support of separate power control parameters for PRACH transmission in additional-ROs and legacy-ROs,
- also support separate powerRampingStep and powerRampingStepHighPriority for additional-ROs.
R1-2501416 Summary#2 on SBFD random access operation Moderator (CMCC)
From Wednesday session
Conclusion
For RACH configuration Option 2, for the case that additional ROs overlap with legacy ROs, support Alt-1:
· Alt-1: do not optimize for this case
Conclusion
For RACH configuration Option 2, and for interpretation of the parameter prach-ConfigurationIndex provided by the additional RACH configuration:
Agreement (confirmed on Thursday with the following changes in red)
For
determination of the Msg3 PUSCH transmission power and when separate preambleReceivedTargetPower
for additional-ROs is configured for RACH configuration Option 1 or Option 2
Companies to check the above proposal for endorsement on Thursday.
Conclusion
For SBFD-aware UEs, there is no restriction on the combination of RO type of the latest PRACH transmission and the symbol type of following Msg3 PUSCH transmission or PUCCH carrying HARQ ACK for Msg4.
Agreement
Consider the following alternatives about power ramping when a SBFD-aware UE switches from additional-ROs to legacy-ROs and from legacy-ROs to additional-ROs (if supported) in PRACH transmission re-attempt in one RACH procedure for RACH configuration Option 1 and Option 2.
Agreement
For an SBFD aware UE, if additional-RO is selected for PRACH transmission, for Msg3 PUSCH repetition Configuration 1,
Agreement
For RACH configuration Option 1, when separate configuration of rsrp-ThresholdMsg1-RepetitionNum2/4/8 for PRACH transmission with preamble repetitions within additional-ROs is not configured, the rsrp-ThresholdMsg1-RepetitionNum2/4/8 configured for PRACH transmission with preamble repetitions within legacy-ROs is reused for additional-ROs.
R1-2501417 Summary#3 on SBFD random access operation Moderator (CMCC)
From Thursday session
Conclusion
There is no consensus in RAN1 to support Type-2 random access procedure (2-step RACH) in SBFD symbols for SBFD-aware UEs.
Agreement
For RACH configuration Option 1, down-select from the following two alternatives:
· Alt-1: Shared ssb-SharedRO-MaskIndex configuration for Additional-ROs and Legacy-ROs.
· Alt-2: Separate ssb-SharedRO-MaskIndex configurations for Additional-ROs and Legacy-ROs.
R1-2500095 On cross-link interference handling for subband full duplex Huawei, HiSilicon
R1-2500146 Discussion on CLI handling for Rel-19 duplex operation ZTE Corporation, Sanechips
R1-2500168 Discussion on CLI handling Spreadtrum, UNISOC
R1-2500223 Discussion on CLI handling for NR duplex evolution CATT
R1-2500251 Discussion on CLI handling LG Electronics
R1-2500285 Discussion on CLI handling CMCC
R1-2500316 Discussion on CLI Handling in SBFD system MediaTek Inc.
R1-2500348 Discussion on CLI handling for Rel-19 NR duplex vivo
R1-2500403 Discussion on gNB-gNB CLI handling Tejas Networks Limited
R1-2500456 CLI handling in NR duplex operation OPPO
R1-2500522 Discussion on CLI handling for SBFD operation InterDigital, Inc.
R1-2500588 CLI handling for NR duplex operations NEC
R1-2500650 SBFD CLI handling Sony
R1-2500707 Discussion on CLI handling Panasonic
R1-2500731 Discussion on CLI handling for SBFD operation Xiaomi
R1-2500751 CLI handling Ericsson
R1-2500777 Discussion on CLI handling Apple
R1-2500849 Cross-link interference handling for SBFD Samsung
R1-2500882 Discussion on CLI handling CEWiT
R1-2500910 Discussion on CLI handling for SBFD operation ETRI
R1-2501005 Cross-link interference handling for duplex evolution Nokia, Nokia Shanghai Bell
R1-2501061 Cross-link interference (CLI) handling Sharp
R1-2501155 Enhancements for CLI handling Qualcomm Incorporated
R1-2501201 Discussion on CLI handling NTT DOCOMO, INC.
R1-2501292 On the gNB-to-gNB CLI and the UE-to-UE CLI handling Google Ireland Limited
R1-2501353 Discussion on CLI handling for Rel-19 NR duplex vivo
R1-2501455 Summary #1 of CLI handling Moderator (Huawei)
From Tuesday session
Agreement
For the semi-statically configured time location and frequency location of UL muting symbol(s) for PUSCH,
· Separate configurations of up to two UL muting symbols can be provided per UE for DG PUSCH/Type 2 CG PUSCH and Type 1 CG PUSCH
o Separate configuration for each of multiple Type 1 CG PUSCH configurations is supported
Agreement
For PUSCH that is scheduled by DCI format 0_0 or Type 2 CG PUSCH activated by DCI format 0_0, UL resource muting is not applied.
Agreement
Confirm the following working assumption
Working assumption
For the frequency location configuration of UL resource muting for a PUSCH, for DFT-S-OFDM
- A comb offset {0, 1} is configured for the up to two UL muting symbols
Agreement
For the configuration of UL resource muting
· Alt.1: A new IE PUSCH-MutingResources is introduced to define the time location and frequency location of UL muting resources. The UL muting pattern configures up to two symbols within a slot and a configurable comb offset.
Agreement
For a CSI report with CSI-ReportConfig with higher layer parameter reportQuantity set to ‘cli-RSSI’ or ‘cli-SRS-RSRP’
· carrier in CSI-ReportConfig is used to indicate in which serving cell the CLI-RSSI measurement resources or SRS-RSRP measurement resources in CSI-ResourceConfig are to be found. If the field is absent, the resources are on the same serving cell as this report configuration.
· bwp-Id in the associated CSI-ResourceConfig is used to indicate the DL BWP where the CLI-RSSI measurement resources or SRS-RSRP measurement resources are located in.
Note: No RAN1 specification impact.
R1-2501456 Summary #2 of CLI handling Moderator (Huawei)
From Wednesday session
Agreement
A new parameter ul-MutingIndicator is introduced to PUSCH-Allocation-r16 to indicate whether the semi-statically configured UL muting symbol(s) is enabled.
Agreement
The following agreement replaces the earlier agreement from RAN1#119
If transform precoding is enabled for a PUSCH, the following options are provided for the purpose of specification drafting (how UE implementation is done is left to each company).
for symbol(s) with
UL resource muting modulated symbols
are transformed to the frequency domain with a DFT of size , and the result
is mapped to the unmuted scheduled
subcarriers. 
for symbol(s) with
UL resource muting modulated symbols
is repeated before DFT. After DFT, the non-zero
even-indexed subcarriers are extracted and then mapped to the unmuted
scheduled subcarriers. modulated symbols
is extended to modulated symbols
by inserting ‘0’ after every modulated symbol. After DFT, the first subcarriers are
extracted and then mapped to the unmuted scheduled subcarriers.Note:
is the total number of
subcarriers of the PUSCH.
Note: Above options are mathematically equivalent.
Note: It is up to the spec editor how to capture the above as long as the specification captures the above in a mathematically identical manner.
Agreement
For the PUSCH symbol containing PT-RS with UL resource muting when transform precoding is not enabled, 3 dB power boosting for both PUSCH and PTRS REs if present, regardless of the PTRS density K and number of PUSCH layers L.
Agreement
· UE determines the subcarrier spacing of the CLI-RSSI measurement resources configured in a CSI-ResourceConfig based on the subcarrier spacing of the DL BWP identified by the higher-layer parameter bwp-Id in the CSI-ResourceConfig.
· UE determines the subcarrier spacing of the SRS-RSRP measurement resources configured in a CSI-ResourceConfig based on the subcarrier spacing of the DL BWP identified by the higher-layer parameter bwp-Id in the CSI-ResourceConfig.
· Note: No RAN1 spec impact is expected.
Agreement
Update the following agreement in RAN1#118 (in red)
For frequency resource allocation of a CLI-RSSI measurement resource, the following are supported:
·
Measurement
resource type#1: OneThe CLI-RSSI measurement resource is configured within
a DL subband or a UL subband.
·
Measurement
resource type#2: OneThe CLI-RSSI measurement resource is configured across
two DL subbands.
· FFS: Number of resources that can be configured.
FFS: UE behavior for measurement.
Working assumption
For L1 based CLI measurement and reporting, the following is adopted
· For L1 SRS-RSRP, a 7-bit value in the quantization range [-140, -44] dBm with 1dB step size, and the differential L1 SRS-RSRP is quantized to a 4-bit value. The differential L1 SRS-RSRP value is computed with 2 dB step size with a reference to the largest measured L1 SRS-RSRP value.
· For L1 CLI-RSSI, a 7-bit value in the quantization range [-100, -25] dBm with 1dB step size, and the differential L1 CLI RSSI is quantized to a 4-bit value. The differential L1 CLI-RSSI value is computed with 2 dB step size with a reference to the largest measured L1 CLI-RSSI value.
Send an LS to RAN4 about the above working assumption.
R1-2501619 [Draft] LS on L1 based UE-to-UE CLI measurement and reporting Moderator (Huawei)
Thursday decision: The draft LS is endorsed. Final version is approved in R1-2501620.
Agreement
For discussion purpose, SRS-RSRP measurement resource index is referred to as SRS-RSRP-MRI and CLI-RSSI measurement resource index is referred to as SRS-RSRP-MRI.
The mapping order of CSI fields of one report for SRS-RSRP-MRI/SRS-RSRP or CLI-RSSI-MRI/CLI-RSSI reporting is provided in Table 1 with following modifications based on Table 6.3.1.1.2-8 defined in TS38.212
· CRI and SSBRI is replaced with SRS-RSRP-MRI or CLI-RSSI-MRI.
· Capability index is crossed out in the table.
· RSRP is replaced with L1-SRS-RSRP
· L1-CLI-RSSI is added in the table if the CSI report is associated with CLI-RSSI measurement resource.
Table 1: Mapping order of CSI fields of one report for SRS-RSRP-MRI/SRS-RSRP or CLI-RSSI-MRI/CLI-RSSI
|
CSI report number |
CSI fields |
|
CSI report #n |
SRS-RSRP-MRI or CLI-RSSI-MRI #1 as in Table 2, if reported |
|
SRS-RSRP-MRI or CLI-RSSI-MRI #2 as in Table 2, if reported |
|
|
… |
|
|
SRS-RSRP-MRI or CLI-RSSI-MRI #4 as in Table 2, if reported |
|
|
L1-SRS-RSRP or L1-CLI-RSSI #1 as in Table 2, if reported |
|
|
Differential L1-SRS-RSRP or L1-CLI-RSSI #2 as in Table 2, if reported |
|
|
… |
|
|
Differential L1-SRS-RSRP or L1-CLI-RSSI #4 as in Table 2, if reported |
Table 2. Bitwidth for SRS-RSRP-MRI, SRS-RSRP, CLI-RSSI-MRI and CLI-RSSI
|
Field |
Bitwidth |
|
SRS-RSRP-MRI |
|
|
CLI-RSSI-MRI |
|
|
L1-SRS-RSRP |
7 |
|
L1-CLI-RSSI |
7 |
|
Differential RSRP |
4 |
|
Differential RSSI |
4 |
: Number of SRS-RSRP
measurement resources in the corresponding resource set
: Number of
CLI-RSSI measurement resources in the corresponding resource set
R1-2501457 Summary #3 of CLI handling Moderator (Huawei)
From Thursday session
Agreement
For PUSCH repetition Type A in SBFD symbols with Configuration 2, the same time location of none, one or two UL muting symbol(s) is applied for all PUSCH repetitions in SBFD symbols.
For PUSCH repetition Type B in SBFD symbols with Configuration 2, the same time location of none, one or two UL muting symbol(s) per slot is applied for all the actual PUSCH repetitions in SBFD symbols.
Note: whether UL resource muting is also applied in non-SBFD symbols is discussed separately
Agreement
For UL muting applied for UL TBoMS, the index of the starting coded bit in a slot, except the first slot, within the 𝑁𝑠 slots allocated for the transmission of TB processing over multiple slots is determined according to Section 6.2.5, TS38.212 as follows
and H is down-selected from one of the following options
· Option 1: 𝐻 is the total number of coded bits available for transmission of the transport block in the previous slot within the 𝑁𝑠 slots assuming no UCI multiplexing and assuming no muted REs.
· Option 2: 𝐻 is the total number of coded bits available for transmission of the transport block in the previous slot within the 𝑁𝑠 slots assuming no UCI multiplexing and considering the muted REs
Note: No impact on TBS determination in Option 1 or Option 2.
Agreement
Conclusion
For a CSI report with CSI-ReportConfig with higher layer parameter reportQuantity set to ‘cli-RSSI’ or ‘cli-SRS-RSRP’, new reporting criteria considering the least interfered measured L1-CLI-RSSI or L1-SRS-RSRP are not supported.
Agreement
For L1 CLI measurement and reporting, the number of occupied CPU(s) is determined as follows
·
for a CSI report with CSI-ReportConfig with higher layer
parameter reportQuantity set to ‘cli-RSSI’,
‘cli-SRS-RSRP’.
Agreement
If the scheduling offset between the last symbol of the PDCCH carrying the triggering DCI for aperiodic CLI reporting and the first symbol of the aperiodic SRS-RSRP measurement resource or CLI-RSSI measurement resources is smaller than the UE reported threshold beamSwitchTiming, down-select from the following alternatives:
· Alt.1: UE does not expect to be configured with a scheduling offset between the last symbol of the PDCCH carrying the triggering DCI for AP CLI and the first symbol of the aperiodic CLI SRS-RSRP or CLI-RSSI resources is smaller than the UE reported threshold beamSwitchTiming.
· Alt.2: Same default beam rules as AP CSI-RS resource defined in 38.214 can be applied to AP CLI SRS-RSRP or CLI-RSSI resource.
FFS: whether Alt.1 or Alt.2 has any specification impact.
R1-2501458 Summary #1 of discussion on RRC parameters for 9.3.3 Moderator (Huawei)
Please refer to RP-241614 for detailed scope of the WI.
[120bis-R19-Duplex] – Xinghua (Huawei)
Email discussion on Rel-19 SBFD
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2502245 Higher layer parameters for Rel-19 SBFD Huawei, HiSilicon
Including semi-static indication of SBFD resources.
R1-2501738 Discussion on SBFD TX/RX/measurement procedures MediaTek Inc
R1-2501752 Discussion on SBFD TX/RX/measurement procedures LG Electronics
R1-2501803 Discussion on Rel-19 SBFD operation vivo
R1-2501843 Discussion on SBFD TX/RX/measurement procedures TCL
R1-2501865 Discussion on SBFD TX/RX/measurement procedures Spreadtrum, UNISOC
R1-2501907 Discussion on transmission, reception and measurement procedures for SBFD operation ZTE Corporation, Sanechips
R1-2501928 On SBFD TX_RX_measurement procedures InterDigital, Inc.
R1-2501989 Discussion on SBFD TX/RX/measurement procedures CATT
R1-2502013 Discussion for SBFD TX/RX/ measurement procedures Tejas Network Limited
R1-2502020 Discussion on SBFD TX/RX/measurement procedures China Telecom
R1-2502040 Discussion on SBFD TX/RX/measurement procedures Ofinno
R1-2502121 Discussion on SBFD Tx/Rx/measurement procedures Fujitsu
R1-2502157 Discussion on SBFD TX/RX/measurement procedures CMCC
R1-2502197 Discussion on subband non-overlapping full duplex Tx-Rx and measurement operations NEC Late submission
R1-2502241 On subband full duplex design Huawei, HiSilicon
R1-2502277 Discussion on SBFD Tx/Rx/measurement procedures OPPO
R1-2502315 SBFD procedures Sony
R1-2502365 SBFD operation and procedures Samsung
R1-2502402 Discussion on SBFD TX/RX/measurement procedures Panasonic
R1-2502405 On SBFD TX/RX/measurement procedures Nokia, Nokia Shanghai Bell
R1-2502420 SBFD TX/RX/measurement procedures Ericsson
R1-2502438 Discussion on reception and transmission procedure for SBFD operation Xiaomi
R1-2502497 Discussion on SBFD Tx/Rx/measurement procedures Fraunhofer HHI, Fraunhofer IIS
R1-2502508 Discussion on SBFD TX/RX/measurement procedures ETRI
R1-2502540 Discussion on SBFD operation Transsion Holdings
R1-2502602 Discussion on SBFD TX/RX/measurement procedures Apple
R1-2502652 Discussion on SBFD Tx/Rx/measurement procedures Charter Communications, Inc
R1-2502656 SBFD Tx/Rx/measurement aspects Sharp
R1-2502668 Discussion on SBFD TX/RX/measurement procedures Kookmin University
R1-2502680 Partial PRG handling for SBFD ASUSTeK
R1-2502689 Discussion on SBFD TX/RX/measurement procedures HONOR
R1-2502763 Discussion on SBFD TX/RX/measurement procedures NTT DOCOMO, INC.
R1-2502794 Discussion on SBFD TX/RX/measurement procedures ITRI
R1-2502836 SBFD Transmission, Reception and Measurement Procedures Qualcomm Incorporated
R1-2502901 Discussion on SBFD TX/RX/measurement procedures Google Korea LLC
R1-2502913 Discussion on SBFD TX/RX/measurement procedures CEWiT
R1-2502925 Discussion on SBFD TX/RX/measurement procedures WILUS Inc.
R1-2502798 Summary #1 of SBFD TX/RX/measurement procedures Moderator (Xiaomi)
From Tuesday session
Agreement
For PUSCH repetition type B, if the actual repetitions are across SBFD symbols and non-SBFD symbols in the same slot or different slots where each transmission occasion has either all SBFD or all non-SBFD symbols (i.e. Configuration 2), the PRBs for actual repetitions in SBFD and non-SBFD symbols are determined in the same way as for PUSCH repetition type A with Configuration 2.
is not
configured, it is zero
Agreement
For PUSCH transmissions with Configuration 2, the determination of PRBs (starting PRB) in SBFD symbols for RA type 0 is the same as that for RA type 1 without additional optimization.
· Number PRBs follow existing RAN1 agreement.
Conclusion
For separate SRS-ResourceSets configurations for SBFD symbols and non-SBFD symbols for a given usage, frequency hopping counter for an SRS resource is calculated as legacy.
Agreement
For a physical channel/signal occasion mapped to SBFD and non-SBFD symbols within a slot,
· For PUSCH repetition type A with available slot counting, A-SRS with available slot counting, TBoMS and PUCCH repetitions, UE postpones a transmission if the transmission occasion is mapped to SBFD and non-SBFD symbols within a slot.
· For CG PUSCH with neither TBoMS nor PUSCH repetition type A with available slot counting, SPS PDSCH, P/SP SRS, P/SP CSI-RS, P/SP PUCCH, SP-CSI on PUSCH, PUSCH repetition type A without available slot counting, multi-PUSCH/PDSCH scheduled by a single DCI, and PDSCH repetitions, UE drops a transmission/reception if the transmission/reception occasion is mapped to SBFD and non-SBFD symbols within a slot.
Agreement
Separate SRS-ResourceSets configurations for SBFD and non-SBFD symbols is applicable for usage set to 'beamManagement'.
· The total number of SRS-ResourceSets applicable for usage set to 'beamManagement’ is the same as legacy.
Conclusion
For SPS HARQ-ACK transmission when Configuration 1 is configured for the UL BWP, the symbol type can be different for different PUCCH transmission occasions.
Agreement
For PUCCH repetition, PUSCH repetition with available counting and TBoMS with Configuration 1,
· In case the valid symbol type is SBFD symbol, a slot is determined as available if the symbols allocated for PUCCH/PUSCH in the slot are all SBFD symbols and not include a symbol of an SS/PBCH block with index provided by ssb-PositionsInBurst.
· In case the valid symbol type is non-SBFD symbol, a slot is determined as available if the symbols allocated for PUCCH/PUSCH in the slot are all non-SBFD symbols and not include a DL symbol indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated if provided or a symbol of an SS/PBCH block with index provided by ssb-PositionsInBurst.
Agreement
For PUCCH repetition, PUSCH repetition with available counting and TBoMS with Configuration 2, a slot is determined as available if
· the symbols allocated for PUCCH/PUSCH in the slot are all SBFD symbols and not include a symbol of an SS/PBCH block with index provided by ssb-PositionsInBurst, or
· the symbols allocated for PUCCH/PUSCH in the slot are all non-SBFD symbols and not include a DL symbol indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated if provided or a symbol of an SS/PBCH block with index provided by ssb-PositionsInBurst.
R1-2502799 Summary #2 of SBFD TX/RX/measurement procedures Moderator (Xiaomi)
From Wednesday session
Agreement:
For PUSCH repetition type B, adopt Option 1.
· Option 1: A nominal repetition is segmented into actual repetitions around boundary of SBFD symbols and non-SBFD symbols.
Agreement
For PUSCH repetition Type B with Configuration 1:
R1-2501739 Discussion on SBFD Random Access Operation MediaTek Inc
R1-2501753 Discussion on SBFD random access operation LG Electronics
R1-2501804 Discussion on random access for Rel-19 SBFD vivo
R1-2501844 Discussion on SBFD random access operation TCL
R1-2501866 Discussion on SBFD random access operation Spreadtrum, UNISOC
R1-2501908 Discussion on SBFD random access operation ZTE Corporation, Sanechips
R1-2501929 On SBFD random access operation InterDigital, Inc.
R1-2501990 Discussion on SBFD random access operation CATT
R1-2502014 Discussion on SBFD Random Access Operation Tejas Network Limited
R1-2502021 Discussion on SBFD random access operation China Telecom
R1-2502041 Discussion on SBFD random access operation Ofinno
R1-2502085 Discussion on random access for SBFD NEC
R1-2502122 Discussion on SBFD random access operation Fujitsu
R1-2502158 Discussion on SBFD random access operation CMCC
R1-2502242 On subband full duplex random access operation Huawei, HiSilicon
R1-2502278 Discussion on SBFD random access operation OPPO
R1-2502316 SBFD RACH operations Sony
R1-2502366 Random access on SBFD resources Samsung
R1-2502404 Discussion on SBFD random access operation Panasonic
R1-2502406 SBFD random access operation Nokia, Nokia Shanghai Bell
R1-2502421 SBFD Random access operation Ericsson
R1-2502439 Discussion on SBFD random access operation Xiaomi
R1-2502494 Discussion on SBFD random access operation Korea Testing Laboratory
R1-2502509 SBFD random access operation ETRI
R1-2502541 Discussion on SBFD random access operation Transsion Holdings
R1-2502557 On SBFD random access operation Google Korea LLC
R1-2502568 SBFD random access operation Lenovo
R1-2502577 Discussion on SBFD random access remaining aspects Fainity Innovation
R1-2502603 Views on SBFD random access operation Apple
R1-2502657 SBFD random access aspects Sharp
R1-2502669 Discussion on SBFD random access operation Kookmin University
R1-2502764 Discussion on SBFD random access operation NTT DOCOMO, INC.
R1-2502795 Discussion on SBFD random access operation ITRI
R1-2502837 SBFD Random Access Operation Qualcomm Incorporated
R1-2502926 Discussion on SBFD random access operation WILUS Inc.
R1-2503016 Summary#1 on SBFD random access operation Moderator (CMCC)
From Tuesday
Conclusion
For RACH configuration Option 1, there is no consensus in RAN1 to support separate ssb-SharedRO-MaskIndex configurations for Additional-ROs and Legacy-ROs under the same FeatureCombinationPreambles configuration and it’s up to RAN2 to decide whether to support separate featureCombinationPreamblesList configurations for Additional-ROs and Legacy-ROs.
Agreement
For CBRA, if a SBFD-aware UE transmits Msg1 in legacy-RO, the UE follows the legacy behavior during the random access procedure.
· FFS: Whether specification change is necessary
Agreement
For determination of the Msg3 PUSCH transmission power for RACH configuration Option 2:
· preambleReceivedTargetPower configured for legacy-RO is used if Msg3 PUSCH is transmitted in non-SBFD symbols;
· preambleReceivedTargetPower configured for additional-RO is used if Msg3 PUSCH is transmitted in SBFD symbols;
· FFS whether/how to support separate msg3-DeltaPreamble for non-SBFD symbols and SBFD-symbols.
Agreement
It is up to RAN2 to determine the following issues for PRACH transmission with preamble repetition:
· RO group selection for initial PRACH transmission attempt in one RACH procedure.
· RO group switch for PRACH transmission re-attempt in one RACH procedure.
Agreement
For SBFD-aware UEs, support separate configuration of msg3-Alpha for Msg3 PUSCH transmission on SBFD symbols. When separate msg3-Alpha for Msg3 PUSCH transmission on SBFD symbols is configured:
· msg3-Alpha configured for Msg3 PUSCH transmission on non-SBFD symbols is used if Msg3 PUSCH is transmitted in non-SBFD symbols;
· msg3-Alpha configured for Msg3 PUSCH transmission on SBFD symbols is used if Msg3 PUSCH is transmitted in SBFD symbols.
Agreement
For SBFD-aware UEs, support separate configuration of p0-nominal for PUCCH on SBFD symbols. When separate p0-nominal for PUCCH on SBFD symbols is configured:
· p0-nominal configured for PUCCH on non-SBFD symbols is used if PUCCH is transmitted in non-SBFD symbols;
· p0-nominal configured for PUCCH on SBFD symbols is used if PUCCH is transmitted in SBFD symbols.
Agreement
For RACH configuration Option 1 and Option 2, indexing of the PRACH occasion indicated by the mask index value for Additional-ROs is performed separately from Legacy-ROs following legacy indexing rules.
Agreement
For RACH configuration Option 1 and Option 2, when a SBFD-aware UE switches from additional-ROs to legacy-ROs in PRACH transmission re-attempt in one RACH procedure, support Alt-1: Increase the power ramping counter.
R1-2503017 Summary#2 on SBFD random access operation Moderator (CMCC)
From Wednesday session
Agreement
Update the following agreement made in RAN1#118-bis in red:
Agreement
For SBFD aware UEs, for Msg3 PUSCH transmission in SBFD symbols, reuse Table 8.3-1 in TS 38.213 for determination of the frequency offset for the 2nd hop, with the update that the frequency offset for 2nd hop is based on the size of UL usable PRBs.
-
FFS the case
when the value of 
= 11
-
FFS the
definition of UL usable PRBs for Msg3 PUSCH transmission
Agreement
·
For
determination of Msg3 PUSCH transmission power, 
is provided by MAC layer and is the amount
of power ramping applied to the latest Random Access Preamble transmission,
regardless of the used RO types and symbol type of Msg3 PUSCH.
·
FFS: For RACH configuration
Option 2, interpretation of when separate PREAMBLE_POWER_RAMPING_STEP configurations for different RO types when
UE switches from additional-ROs to legacy-ROs.
o This does not imply that separate PREAMBLE_POWER_RAMPING_STEP configurations are supported.
Conclusion
For RACH configuration Option 2, when a SBFD-aware UE switches from additional-ROs to legacy-ROs in PRACH transmission re-attempt in one RACH procedure, there is no RAN1 consensus to support a power offset to compensate the power ramping difference.
Conclusion
There is no RAN1 consensus on the following proposal:
· For RACH configuration Option 1 with Alt 1-1, for determination of lowest RO of additional-ROs in SBFD symbols, the parameter msg1-FrequencyStart in rach-ConfigCommon is reinterpreted as the frequency offset of lowest RO in frequency domain with respective to the lowest PRB of UL usable PRBs ONLY if there is no legacy-RO configured in SBFD symbols configured as flexible by tdd-UL-DL-ConfigurationCommon.
Final summary in R1-2503018.
R1-2501740 Discussion on CLI Handling in SBFD System MediaTek Inc
R1-2501754 Discussion on CLI handling LG Electronics
R1-2501805 Discussion on CLI handling for Rel-19 NR duplex vivo
R1-2501867 Discussion on CLI handling Spreadtrum, UNISOC
R1-2501909 Discussion on CLI handling for Rel-19 duplex operation ZTE Corporation, Sanechips
R1-2501930 On CLI handling for SBFD operation InterDigital, Inc.
R1-2501991 Discussion on CLI handling for NR duplex evolution CATT
R1-2502015 Discussion on gNB-gNB CLI handling Tejas Network Limited
R1-2502086 CLI handling for NR duplex operations NEC
R1-2502159 Discussion on CLI handling CMCC
R1-2502243 On cross-link interference handling for subband full duplex Huawei, HiSilicon
R1-2502279 CLI handling in NR duplex operation OPPO
R1-2502317 SBFD CLI handling Sony
R1-2502367 Cross-link interference handling for SBFD Samsung
R1-2502407 Cross-link interference handling for duplex evolution Nokia, Nokia Shanghai Bell
R1-2502410 Discussion on CLI handling Panasonic
R1-2502422 CLI handling Ericsson
R1-2502440 Discussion on CLI handling for SBFD operation Xiaomi
R1-2502510 Discussion on CLI handling for SBFD operation ETRI
R1-2502558 On the gNB-to-gNB CLI and the UE-to-UE CLI handling Google Korea LLC
R1-2502604 Discussion on CLI handling Apple
R1-2502650 Cross-link interference (CLI) handling Sharp
R1-2502958 Discussion on CLI handling NTT DOCOMO, INC. (rev of R1-2502765)
R1-2502838 Enhancements for CLI handling Qualcomm Incorporated
R1-2502914 Discussion on CLI Handling CEWiT
R1-2503035 Summary #1 of CLI handling Moderator (Huawei)
From Tuesday session
Agreement
Send a follow-up LS to RAN4 with the following RAN1 agreement from RAN#120 on power boosting in symbols containing PTRS and RAN4 may check impact on transmit signal quality/MPR. See final LS in R1-2503089 below.
Agreement
For the PUSCH symbol containing PT-RS with UL resource muting when transform precoding is not enabled, 3 dB power boosting for both PUSCH and PTRS REs if present, regardless of the PTRS density K and number of PUSCH layers L.
Agreement
Update the agreement in RAN1#120 as follows (highlighted in red):
Agreement
For discussion purpose, SRS-RSRP measurement resource index is referred
to as SRS-RSRP-MRI and CLI-RSSI measurement resource index is referred to as SRS-RSRP-MRICLI-RSSI-MRI.
The mapping order of CSI fields of one report for SRS-RSRP-MRI/SRS-RSRP or CLI-RSSI-MRI/CLI-RSSI reporting is provided in Table 1 with following modifications based on Table 6.3.1.1.2-8 defined in TS38.212
· CRI and SSBRI is replaced with SRS-RSRP-MRI or CLI-RSSI-MRI.
· Capability index is crossed out in the table.
· RSRP is replaced with L1-SRS-RSRP
· L1-CLI-RSSI is added in the table if the CSI report is associated with CLI-RSSI measurement resource.
Table 1: Mapping order of CSI fields of one report for SRS-RSRP-MRI/SRS-RSRP or CLI-RSSI-MRI/CLI-RSSI
|
CSI report number |
CSI fields |
|
CSI report #n |
SRS-RSRP-MRI or CLI-RSSI-MRI #1 as in Table 2, if reported |
|
SRS-RSRP-MRI or CLI-RSSI-MRI #2 as in Table 2, if reported |
|
|
… |
|
|
SRS-RSRP-MRI or CLI-RSSI-MRI #4 as in Table 2, if reported |
|
|
L1-SRS-RSRP or L1-CLI-RSSI #1 as in Table 2, if reported |
|
|
Differential L1-SRS-RSRP or L1-CLI-RSSI #2 as in Table 2, if reported |
|
|
… |
|
|
Differential L1-SRS-RSRP or L1-CLI-RSSI #4 as in Table 2, if reported |
Table 2. Bitwidth for SRS-RSRP-MRI, SRS-RSRP, CLI-RSSI-MRI and CLI-RSSI
|
Field |
Bitwidth |
|
SRS-RSRP-MRI |
|
|
CLI-RSSI-MRI |
|
|
L1-SRS-RSRP |
7 |
|
L1-CLI-RSSI |
7 |
|
Differential RSRP |
4 |
|
Differential RSSI |
4 |
: Number of SRS-RSRP measurement resources
in the corresponding resource set
: Number of CLI-RSSI measurement resources
in the corresponding resource set
Agreement
For periodic L1 CLI-RSSI reporting on PUCCH based on a set of periodic CLI measurement resources, the TCI state(s) with QCL typeD for the CLI measurement resources in the periodic CLI measurement resource set are configured per CLI measurement resource (either for all resources in the set or none) by higher-layer parameter
Agreement
The existing CSI timeline for L1 RSRP reporting is reused for the aperiodic CLI measurement and reporting in Rel-19 SBFD.
· FFS: whether the slot offset between the slot containing the DCI that triggers a set of aperiodic SRS-RSRP resources and the slot in which the SRS-RSRP resource set is measured shall not be smaller than 1.
Agreement
For the following question from the RAN4 LS in R1-2501698:
- RAN4 respectfully asks RAN1 to clarify whether the NW configuration of timeRestrictionForChannelMeasurement or a similar configuration will apply for L1-SRS-RSRP and/or L1-CLI-RSSI measurement.
o RAN1 informs RAN4 that the NW configuration of timeRestrictionForChannelMeasurement will apply for L1-SRS-RSRP and L1-CLI-RSSI measurement.
- RAN4 kindly asks whether RAN1 will define optional UE capability for FDM-ed DL reception and SRS measurement.
o RAN1 informs RAN4 that a new optional UE capability will be defined for FDM-ed DL reception and SRS measurement.
Agreement
For UL muting applied for UL TBoMS, the index of the starting coded bit in a slot, except the first slot, within the 𝑁𝑠 slots allocated for the transmission of TB processing over multiple slots is determined according to Section 6.2.5, TS38.212 as follows
and 𝐻 is the total number of coded bits available for transmission of the transport block in the previous slot within the 𝑁𝑠 slots assuming no UCI multiplexing and considering the muted REs.
FFS: Whether additional specification impact is needed to support above.
R1-2503036 Summary #2 of CLI handling Moderator (Huawei)
From Wednesday session
Agreement
When transform precoding is enabled and an UL muting symbol overlaps a symbol containing PT-RS, down-select from the following alternatives in RAN1#121
samples prior to transform precoding
and 
are determined as legacy from 38.214 Table 6.2.3.2-1
groups
Agreement
Configuration of Method 1 or Method 3 are not explicitly provided for L1 CLI-RSSI measurement and reporting. Configuration of Measurement resource type #1 or Measurement resource type #2 are not explicitly provided for L1 CLI-RSSI measurement.
Conclusion
There is no RAN1 consensus to support two new report quantities {‘cli-RSSI-measurement-resource-bitmap’, ‘cli-SRS-RSRP-measurement-resource-bitmap’} to reportQuantity.
R1-2503089 LS on impact on transmit signal quality/MPR requirement RAN1, Huawei
Decision: The LS is approved.
R1-2503090 Reply LS on L1 measurement RAN1, Huawei
Decision: The reply LS on L1 measurement to RAN4 (R4-2502632) is approved.
Please refer to RP-241614 for detailed scope of the WI.
[121-R19-Duplex] Email discussion on Rel-19 SBFD – Xinghua (Huawei)
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2503266 Higher layer parameters for Rel-19 SBFD Huawei, HiSilicon
Including semi-static indication of SBFD resources.
R1-2503261 On subband full duplex design Huawei, HiSilicon
R1-2503327 Discussion on transmission, reception and measurement procedures for SBFD operation ZTE Corporation, Sanechips
R1-2503355 Remaining issues on Rel-19 SBFD operation vivo
R1-2503415 Discussion on subband non-overlapping full duplex Tx-Rx and measurement operations NEC
R1-2503424 Discussion on SBFD TX/RX/measurement procedures LG Electronics
R1-2503441 Discussion on SBFD TX/RX/measurement procedures MediaTek Inc.
R1-2503512 Discussion on SBFD TX/RX/measurement procedures Spreadtrum, UNISOC
R1-2503563 SBFD operation and procedures Samsung
R1-2503623 Discussion on SBFD TX/RX/measurement procedures InterDigital, Inc.
R1-2503629 Discussion on SBFD TX/RX/measurement procedures TCL
R1-2503706 Discussion for SBFD TX/RX/ measurement procedures Tejas Network Limited
R1-2503731 Discussion on SBFD TX/RX/measurement procedures Ofinno
R1-2503759 Discussion on SBFD Tx/Rx/measurement procedures Fraunhofer HHI, Fraunhofer IIS
R1-2503790 Discussion on SBFD TX/RX/measurement procedures CATT
R1-2503827 Discussion on SBFD TX/RX/measurement procedures CMCC
R1-2503879 Discussion on reception and transmission procedure for SBFD operation Xiaomi
R1-2503970 Discussion on SBFD TX/RX/measurement procedures Kookmin University
R1-2504009 Discussion on SBFD TX/RX/measurement procedures Panasonic
R1-2504044 Remaining issues on SBFD TX/RX/measurement procedures China Telecom
R1-2504086 Discussion on SBFD Tx/Rx/measurement procedures Fujitsu
R1-2504097 Discussion on SBFD TX/RX/measurement procedures HONOR
R1-2504121 On SBFD TX/RX/measurement procedures Nokia, Nokia Shanghai Bell
R1-2504136 Discussion on SBFD TX/RX/measurement procedures ETRI
R1-2504174 Discussion on SBFD operation Transsion Holdings
R1-2504209 Discussion on SBFD Tx/Rx/measurement procedures OPPO
R1-2504286 SBFD TX/RX Measurement Procedures Lenovo
R1-2504289 Discussion on SBFD Tx/Rx/measurement procedures Charter Communications, Inc
R1-2504315 Remaining issues on SBFD TX/RX/measurement procedures Apple
R1-2504391 SBFD Transmission, Reception and Measurement Procedures Qualcomm Incorporated
R1-2504478 SBFD Tx/Rx/measurement aspects Sharp
R1-2504498 Discussion on SBFD TX/RX/measurement procedures NTT DOCOMO, INC.
R1-2504536 Discussion on SBFD TX/RX/measurement procedures ITRI, Acer Incorporated
R1-2504559 Partial PRG handling for SBFD ASUSTeK
R1-2504582 Discussion on SBFD TX/RX/measurement procedures Google Korea LLC
R1-2504594 Summary #2 of SBFD TX/RX/measurement procedures Moderator (Xiaomi)
R1-2504598 Discussion on SBFD TX/RX/measurement procedures CEWiT
R1-2504609 SBFD TX/RX/measurement procedures Ericsson
R1-2504615 Discussion on SBFD TX/RX/measurement procedures WILUS Inc.
R1-2504626 SBFD procedures Sony
R1-2504593 Summary #1 of SBFD TX/RX/measurement procedures Moderator (Xiaomi)
Agreement
For PUSCH repetition Type B, when UE is provided with Configuration #1, UE drops an actual repetition if the actual repetition is in the invalid symbol type.
Agreement
For PUSCH Type B repetition with inter-repetition frequency hopping in SBFD symbols, the starting RB for an actual repetition within the n-th nominal repetition (as defined in Clause 6.1.2.1) is given by:
where
-
is the starting PRB index of UL usable PRBs with reference to the
start of UL active BWP.
-
is the number of UL usable PRBs.
-
is the starting PRB index of the first PUSCH hop with reference to
the start of UL active BWP. For PUSCH transmissions with Configuration 2, is the starting PRB index with reference to the start of UL active BWP after applying RB
offset between non-SBFD symbols and SBFD symbols.
- RB offset is the frequency hopping offset for PUSCH in SBFD symbols
If the n-th nominal repetition is across both SBFD symbols and non-SBFD symbols, the starting RB for an actual repetition in SBFD symbols within the n-th nominal repetition (as defined in Clause 6.1.2.1) is given above, and the starting RB for an actual repetition in non-SBFD symbols within the n-th nominal repetition (as defined in Clause 6.1.2.1) follows the legacy.
Agreement
For PUSCH inter-slot frequency hopping in
SBFD symbols and when pusch-DMRS-Bundling is enabled, the starting RB during slot 
is given by:
Where
-
is the starting PRB index of UL usable PRBs with reference to the
start of UL active BWP.
-
is the number of UL usable PRBs.
-
is the starting PRB index of the first PUSCH hop with reference to
the start of UL active BWP. For PUSCH transmissions with Configuration 2, is the starting PRB index with reference to the start of UL active BWP after applying RB
offset between non-SBFD symbols and SBFD symbols.
- RB offset is the frequency hopping offset for PUSCH in SBFD symbols
Agreement
The number of PRBs of a CSI-RS resource
within a DL subband is ≥ 
, where 
is the number of DL usable PRBs in the DL subband.
Agreement
For each SRS resource set with usage set to 'nonCodebook',
- In case the associated CSI-RS is periodic or semi-persistent, only CSI-RS in the same symbol type as that for SRS is used to calculate SRS precoder.
R1-2504594 Summary #2 of SBFD TX/RX/measurement procedures Moderator (Xiaomi)
Agreement
- From RAN1 perspective, considering the specification impact, SBFD and NR-DC can be configured simultaneously only for inter-band NR-DC if a UE is capable of simultaneous transmission and reception indicated by UE capability simultaneousRxTxInterBandCA, where SBFD operation is applicable on only one NR TDD carrier.
- Inform RAN2 that specification impact to support this feature is not restricted to RAN1 but might result in specification impact on RAN4 as well. If supported, at least the following specification change to TS 38.213 should be adopted and the RAN4 specification for the configured transmitted power level for NR-DC in TS38.101-1 Clause 6.2B.4.1 may also need to be updated accordingly.
|
7.6.2 NR-DC The UE procedures described in this clause are not applicable if the UE is provided scg-State [12, TS 38.331]. If a UE is configured with an MCG using NR radio access in FR1 or in FR2 and with a SCG using NR radio access in FR2 or in FR1, respectively, the UE performs transmission power control independently per cell group as described in clauses 7.1 through 7.5. If a UE is
configured with an MCG and a SCG using NR radio access in FR1 and/or in FR2, the UE is configured a maximum power If a UE is
provided semi-static-mode1 for nrdc-PCmode-FR1 or for nrdc-PCmode-FR2,
or semi-static-mode2 for nrdc-PCmode-FR1 or for nrdc-PCmode-FR2,
the UE does not expect If a UE is
provided semi-static-mode1 for nrdc-PCmode-FR1 or for nrdc-PCmode-FR2,
the UE determines a transmission power for the MCG or
for the SCG as described in clauses 7.1 through 7.5 using If a UE is provided semi-static-mode2 for nrdc-PCmode-FR1 or for nrdc-PCmode-FR2 - if the UE is
not provided tdd-UL-DL-ConfigurationCommon for the MCG or SCG, the UE
determines a transmission power for the MCG or for the SCG as described in
clauses 7.1 through 7.5 using - if at least
one symbol of slot - otherwise, the UE determines a power for
the transmission on SCG or the MCG
overlapping with slot <unchanged texts omitted> |
- It is up to RAN2 to decide whether or not to support simultaneous configuration of SBFD and DC.
- CC: RAN3, RAN4.
Reply LS on simultaneous configuration of SBFD and DC. Final LS in R1-2504858.
Agreement
For a CSI report associated with periodic/semi-persistent CSI-RS, the valid symbol type for CSI derivation configured in CSI-ReportConfig applies to both CMRs and IMRs (limited to NZP-CSI-RS) associated with the CSI report.
Conclusion
Separate configuration of PCMAX/p-max is a RAN4 issue and will not be discussed in RAN1. It is up to RAN4 make decision on this issue. As part of RAN1 study on this issue, one company submitted simulation results in R1-2504391.
Conclusion
There is no RAN1 consensus to support explicit indication of gNB transition period length and/or location between SBFD and non-SBFD symbols.
R1-2504857 Draft reply LS on simultaneous configuration of SBFD and DC Xiaomi
R1-2503262 On subband full duplex random access operation Huawei, HiSilicon
R1-2503328 Discussion on SBFD random access operation ZTE Corporation, Sanechips
R1-2503356 Remaining issues on random access for Rel-19 SBFD vivo
R1-2503425 Discussion on SBFD random access operation LG Electronics
R1-2503442 Discussion on SBFD Random Access Operation MediaTek Inc.
R1-2503513 Discussion on SBFD random access operation Spreadtrum, UNISOC
R1-2503564 Random access on SBFD resources Samsung
R1-2503624 Discussion on SBFD random access operation InterDigital, Inc.
R1-2503626 Discussion on SBFD random access operation Korea Testing Laboratory
R1-2503630 Discussion on SBFD random access operation TCL
R1-2503707 Discussion on SBFD Random Access Operation Tejas Network Limited
R1-2503732 Discussion on SBFD random access operation Ofinno
R1-2503791 Discussion on SBFD random access operation CATT
R1-2503828 Discussion on SBFD random access operation CMCC
R1-2503880 Discussion on SBFD random access operation Xiaomi
R1-2503936 CLI Handling for NR duplex operation NEC
R1-2503971 Discussion on SBFD random access operation Kookmin University
R1-2504010 Discussion on SBFD random access operation Panasonic
R1-2504045 Discussion on SBFD random access operation China Telecom
R1-2504087 Discussion on SBFD random access operation Fujitsu
R1-2504106 SBFD random access operation Lenovo
R1-2504118 Discussion on SBFD random access operation Hyundai Motor Company
R1-2504122 SBFD random access operation Nokia, Nokia Shanghai Bell
R1-2504137 SBFD random access operation ETRI
R1-2504175 Discussion on SBFD random access operation Transsion Holdings
R1-2504210 Discussion on SBFD random access operation OPPO
R1-2504316 Views on SBFD random access operation Apple
R1-2504392 SBFD Random Access Operation Qualcomm Incorporated
R1-2504479 SBFD Random Access Aspects Sharp
R1-2504499 Discussion on SBFD random access operation NTT DOCOMO, INC.
R1-2504537 Discussion on SBFD random access operation ITRI, Acer Incorporated
R1-2504590 On SBFD random access operation Google Ireland Limited
R1-2504610 SBFD Random access operation Ericsson
R1-2504616 Discussion on SBFD random access operation WILUS Inc.
R1-2504627 SBFD RACH operations Sony
R1-2504708 Summary#1 on SBFD random access operation Moderator (CMCC)
Agreement
For RACH configuration Option 2, all parameters in rach-ConfigCommon except for rsrp-ThresholdSSB-SUL can be included in the additional RACH configuration, i.e., sbfd-RACHDualConfig.
Conclusion
There is no RAN1 consensus to support separate initial UL BWP for SBFD-aware UEs. Reuse the legacy rule for determining the frequency domain resource allocation for Msg3 PUSCH transmission in SBFD symbols.
Conclusion
For RACH configuration Option 2, when a SBFD-aware UE switches from additional-ROs to legacy-ROs or from legacy-ROs to additional-ROs in PRACH transmission re-attempt in one RACH procedure, there is no RAN1 consensus to support a power offset to compensate the power ramping difference
Note: The red part has been added to a previous conclusion from RAN1#120bis.
Conclusion
PUCCH repetition for Msg4 HARQ-ACK is not supported in SBFD random access procedure.
Conclusion
There is no consensus in RAN1 to support separate msg3-DeltaPreamble parameters for non-SBFD symbols and SBFD-symbols for RACH configuration Option 2.
R1-2504709 Summary#2 on SBFD random access operation Moderator (CMCC)
Agreement
For SBFD-aware UEs,
- when separate p0-nominal for PUCCH on SBFD symbols is not configured, p0-nominal configured for PUCCH on non-SBFD symbols is used if PUCCH is transmitted on SBFD symbols.
- when separate msg3-Alpha for Msg3 PUSCH transmission on SBFD symbols is not configured, msg3-Alpha configured for Msg3 PUSCH transmission on non-SBFD symbols is used if Msg3 PUSCH transmission is transmitted on SBFD symbols.
Agreement
Update the agreement made in RAN1#120bis in red:
Agreement
For RACH configuration Option 1 and Option 2, when a SBFD-aware UE switches from additional-ROs to legacy-ROs or from legacy-ROs to additional-ROs in PRACH transmission re-attempt in one RACH procedure, support Alt-1: Increase the power ramping counter.
For determination of
Msg3 PUSCH transmission power for RACH configuration Option 2, 
is provided by MAC layer and is the amount of power ramping applied
to the latest Random Access Preamble transmission, regardless of the used RO
types, symbol type of Msg3 PUSCH and RO type switch.
Agreement
Update the following agreement made in RAN1#120-bis in red:
Agreement
For CBRA, if a SBFD-aware UE transmits Msg1
in legacy-RO, the UE follows the legacy behavior during the random access procedureRACH
attempt.
FFS: Whether
specification change is necessary
R1-2503263 On cross-link interference handling for subband full duplex Huawei, HiSilicon
R1-2503329 Discussion on CLI handling for Rel-19 duplex operation ZTE Corporation, Sanechips
R1-2503357 Remaining issues on CLI handling for Rel-19 NR duplex vivo
R1-2503426 Discussion on CLI handling LG Electronics
R1-2503443 Discussion on CLI Handling in SBFD System MediaTek Inc.
R1-2503514 Discussion on CLI handling Spreadtrum, UNISOC
R1-2503565 Cross-link interference handling for SBFD Samsung
R1-2503625 Discussion on CLI handling for SBFD operation InterDigital, Inc.
R1-2503708 Discussion on gNB-gNB CLI handling Tejas Network Limited
R1-2503733 Discussion on CLI handling Ofinno
R1-2503792 Discussion on CLI handling for NR duplex evolution CATT
R1-2503829 Discussion on CLI handling CMCC
R1-2503881 Discussion on CLI handling for SBFD operation Xiaomi
R1-2503937 Discussion on random access for subband non-overlapping full duplex NEC
R1-2504023 Discussion on CLI handling Panasonic
R1-2504123 Cross-link interference handling for duplex evolution Nokia, Nokia Shanghai Bell
R1-2504138 Discussion on CLI handling for SBFD operation ETRI
R1-2504211 CLI handling in NR duplex operation OPPO
R1-2504317 Remaining issues on CLI handling Apple
R1-2504375 Cross-link interference (CLI) handling Sharp
R1-2504393 Enhancements for CLI handling Qualcomm Incorporated
R1-2504500 Discussion on CLI handling NTT DOCOMO, INC.
R1-2504591 On CLI handling for SBFD operation Google Ireland Limited
R1-2504599 Discussion on CLI Handling CEWiT
R1-2504611 SBFD CLI handling Ericsson
R1-2504628 SBFD CLI handling Sony
R1-2504798 Summary #1 of CLI handling Moderator (Huawei)
Agreement
When transform precoding is enabled and an UL muting symbol overlaps a symbol containing PT-RS, UL resource muting is not applied in the PUSCH symbol containing PT-RS
Agreement
For SRS-RSRP measurement resource configuration, the number of SRS antenna ports is 1.
Agreement
A UE does not expect to be simultaneously configured with L3 and L1 UE-to-UE CLI measurement and reporting.
Agreement
A UE does not expect to be configured with
a scheduling offset between the last symbol of the PDCCH carrying the
triggering DCI for AP CLI and the first symbol of the aperiodic CLI SRS-RSRP or
CLI-RSSI resources is smaller than the UE reported threshold beamSwitchTiming, when the reported
value is one of the values of {14, 28, 48}
and enableBeamSwitchTiming is not provided, or is smaller than 48 when the UE provides beamSwitchTiming-r16, enableBeamSwitchTiming is provided.
R1-2504799 Summary #2 of CLI handling Moderator (Huawei)
Agreement
The slot offset between the slot containing the DCI that triggers a set of aperiodic SRS-RSRP resources and the slot in which the SRS-RSRP resource set is measured shall not be smaller than 1.
Agreement
If the number of reported L1-SRS-RSRP measurement resources is M, and the number of L1-SRS-RSRP measurements which are either >=-44dBm or infinity (infinity means UE cannot detect SRS due to too strong signal to measure) is X (0<X<=M), the following are reported within one report
- An indicator corresponding to a codepoint mapping to out-of-range (L1-SRS-RSRP >= -44) or infinity: 7 bits
- For the M-1 L1-SRS-RSRP measurement, a differential reporting method is adopted using -44dbm as the reference: (M-1)*4bits
o No codepoint defined as ‘out-of-range’ or with positive values are introduced in the differential measurement reporting table
Agreement
A UE does not expect to be configured with L1-CLI-RSSI measurements resources within an UL subband and L1-SRS-RSRP measurement resources on the same symbol.
Agreement
A UE configured with UL resource muting can be configured by a new RRC parameter to apply UL resource muting in non-SBFD symbols, if SBFD symbols are configured for the UE
- If configured as ‘enabled’, UL muting is applicable in both SBFD symbols and non-SBFD symbols
- Otherwise, UL muting is applicable only in SBFD symbols
The above configuration does not apply for a UE configured with UL resource muting, if SBFD symbols are not configured for the UE
- UL resource muting is applicable in both flexible symbols and UL symbols
FG 60-1 is not the prerequisite of FG 60-7 and FG60-7a
Agreement
For a CSI report associated with periodic/semi-persistent SRS-RSRP measurement resources or CLI-RSSI measurement resources, the valid symbol type for CSI derivation configured in CSI-ReportConfig is applicable for L1 UE-to-UE CLI measurement and reporting if SBFD symbols are configured for the UE
- UE shall perform L1 UE-to-UE CLI measurement based on the valid symbol type configured in CSI-ReportConfig
The valid symbol type does not apply for a UE if SBFD symbols are not configured for the UE
- UE shall perform L1 UE-to-UE CLI measurement based on the configuration provided in CSI-ResourceConfig indicated by CSI-ReportConfig
FG 60-1 is not the prerequisite of FG 60-8 and FG60-9
Conclusion
CLI reference resource is not introduced for L1 UE-to-UE CLI measurement and reporting
- Note: The existing CSI reference resource definition in section 5.2.2.5 of TS 38.214 are reused with for L1 UE-to-UE CLI measurement and reporting.
Conclusion
There is no RAN1 consensus on the following:
- Dedicated PRACH/SR resources can be configured for UE to report the beam failure caused by CLI.
